एक उपयोगकर्ता के अवसर (भूमिका और अधिकार) मॉड्यूल डिजाइन करना


15

मैं एक MS SQL सर्वर डेटाबेस के लिए एक उपयोगकर्ता प्रमाणीकरण मॉड्यूल को मॉडल करने की कोशिश कर रहा हूं जो कि डेल्फी यूआई एप्लिकेशन का बैक एंड होगा। मूल रूप से, मैं उपयोगकर्ता खाते रखना चाहता हूँ जहाँ उपयोगकर्ता केवल एक समूह का हो। एक समूह के पास अधिकारों की संख्या "n" हो सकती है।

मैं डेटाबेस में पासवर्ड इतिहास भी जोड़ना चाहता हूं, क्योंकि उपयोगकर्ता को एप्लिकेशन सेटिंग (उदाहरण, प्रत्येक 90%) के आधार पर अपना पासवर्ड बदलने की आवश्यकता होगी।

मैं प्रत्येक बार जब उपयोगकर्ता अंदर और बाहर लॉग इन करता हूं, तो मैं एक ईवेंट लॉग करना चाहता हूं। मैं इसे भविष्य में होने वाली अतिरिक्त घटनाओं तक बढ़ा सकता हूं।

नीचे आपको इस पर मेरी पहली दरार मिलेगी। कृपया मुझे इस पर सुधार करने के लिए कोई सुझाव दें, क्योंकि ऐसा करने का यह मेरा पहला अवसर है।

क्या आपको पासवर्ड-नियम / समाप्ति अवधि के लिए भूमिका-आधारित सुरक्षा और बाधाओं के लिए अतिरिक्त विशेषताओं की आवश्यकता है?

डाटाबेस डिजाइन


: एक विस्तार ब्लॉग यहाँ है goo.gl/ATnj6j
सुरेश Kamrushi

1
मुझे कुछ समझ नहीं आ रहा है। उपयोगकर्ता तालिका में आपके पास group_id है। क्या कोई व्यक्ति एक से अधिक समूहों का सदस्य हो सकता है?
जॉनी

जवाबों:


11

आपकी बताई गई आवश्यकताओं के आधार पर, आपका मॉडल बहुत अच्छे आकार में है।

सुधार के लिए यहां कुछ सुझाव दिए गए हैं:

  • आप स्पष्ट रूप से ऐसा नहीं कहते हैं, इसलिए यह कहना मुश्किल है - लेकिन ऐसा लगता है कि आप सीधे उपयोगकर्ता पासवर्ड जमा कर रहे होंगे। यह बहुत बुरा होगा! यदि आप सामान्य प्रमाणीकरण डेटाबेस को देखते हैं, तो पासवर्ड एन्क्रिप्टेड रूप में संग्रहीत किए जाते हैं। आप अक्सर एक passwordकॉलम और एक password_saltकॉलम दोनों देखते हैं ।

  • आपकी USER_LOGSतालिका में एक Eventकॉलम है। आप इस बारे में स्पष्ट नहीं हैं कि यह कैसे आबाद किया जाना है। क्या कोई EVENT_TYPEतालिका होनी चाहिए जो USER_LOGSसंदर्भ देती हो? यह मित्रवत रिपोर्टिंग के लिए बना सकता है। विशिष्ट घटनाओं में लॉग-इन, लॉग-आउट, पासवर्ड विफल, पासवर्ड परिवर्तन, पासवर्ड रीसेट, लॉक-आउट, अनलॉक, शामिल होंगे ...

  • आपकी GROUP_RIGHTSतालिका यह नहीं बताती है कि किसने अधिकार दिए हैं। ऑडिट ट्रेल प्रयोजनों के लिए, लोग अक्सर लॉग का रिकॉर्ड रखते हैं कि किसने और कब बदला। यह आपके लिए एक मुद्दा नहीं हो सकता है।

यहां आपके द्वारा बताई गई व्यावसायिक आवश्यकताओं के बारे में कुछ प्रश्न दिए गए हैं, जो "टेक्स्ट बुक" भूमिका-आधारित सुरक्षा पैटर्न से भिन्न होते हैं:

  • क्या आप वाकई केवल एक समूह में उपयोगकर्ता होना चाहते हैं? भूमिका-आधारित सुरक्षा का लाभ यह है कि भूमिकाएँ बहुत अधिक स्थिर होती हैं, जबकि भूमिकाओं को पूरा करने वाले लोग बहुत बार आते हैं और चले जाते हैं। इसमें शामिल है कि कुछ लोग अक्सर "दो टोपी पहनते हैं"।

  • आपका डिजाइन केवल अनुदान है। कुछ प्रणालियों में अनुदान और संशोधन शामिल हैं । यह आपको यह कहने की अनुमति देता है कि किसी विशेष समूह के लिए व्यापक रूप से उपलब्ध अधिकार उपलब्ध नहीं है।

  • आपके पास USERSआपके डिज़ाइन के अनुसार उपयोगकर्ता और खाते हैं । अक्सर लोगों और उपयोगकर्ता आईडी के बीच अंतर होता है । कुछ उपयोगकर्ता आईडी टीमों या मशीनों के लिए हैं और कुछ लोगों के पास विभिन्न उद्देश्यों के लिए कई उपयोगकर्ता आईडी हैं। क्या यह एक भेद है जो आपके लिए उपयोगी होगा?


3

मुझे लगता है कि उपयोगकर्ता की अनुमति को लागू करने के लिए बिटवाइज़ ऑपरेटर सबसे अच्छा तरीका है। यहां मैं दिखा रहा हूं कि हम इसे मैसकॉल के साथ कैसे लागू कर सकते हैं।

नीचे कुछ नमूना डेटा के साथ एक नमूना तालिका है:

तालिका 1 : अनुमति तालिका को 1,2,4,8..etc (2 के कई) जैसे बिट नाम के साथ स्टोर करने की अनुमति

CREATE TABLE IF NOT EXISTS `permission` (
  `bit` int(11) NOT NULL,
  `name` varchar(50) NOT NULL,
  PRIMARY KEY (`bit`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

तालिका में कुछ नमूना डेटा डालें।

INSERT INTO `permission` (`bit`, `name`) VALUES
(1, 'User-Add'),
(2, 'User-Edit'),
(4, 'User-Delete'),
(8, 'User-View'),
(16, 'Blog-Add'),
(32, 'Blog-Edit'),
(64, 'Blog-Delete'),
(128, 'Blog-View');

तालिका 2 : उपयोगकर्ता आईडी को उपयोगकर्ता आईडी, नाम और भूमिका संग्रहीत करने के लिए। भूमिका की गणना अनुमतियों के योग के रूप में की जाएगी।
उदाहरण:
यदि उपयोगकर्ता 'केतन' के पास 'उपयोगकर्ता-ऐड' (बिट = 1) और 'ब्लॉग-डिलीट' (बिट -64) की अनुमति है, तो भूमिका 65 (1 + 64) होगी।
यदि उपयोगकर्ता 'मेहता' को 'ब्लॉग-व्यू' (बिट = 128) और 'यूजर-डिलीट' (बिट -4) की अनुमति है, तो भूमिका 132 (128 + 4) होगी।

CREATE TABLE IF NOT EXISTS `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(50) NOT NULL,
  `role` int(11) NOT NULL,
  `created_date` datetime NOT NULL
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1;

नमूना डेटा-

INSERT INTO `user` (`id`, `name`, `role`, `created_date`)
   VALUES (NULL, 'Ketan', '65', '2013-01-09 00:00:00'),
   (NULL, 'Mehata', '132', '2013-01-09 00:00:00');

उपयोगकर्ता की अनुमति की अनुमति यदि हम अनुमति प्राप्त करने के लिए नीचे की तुलना में क्वेरी कर सकते हैं, तो लॉगिन करने के बाद यदि हम उपयोगकर्ता की अनुमति को लोड करना चाहते हैं:

SELECT permission.bit,permission.name  
   FROM user LEFT JOIN permission ON user.role & permission.bit
 WHERE user.id = 1

यहाँ user.role "और" permission.bit एक बिटवाइज़ ऑपरेटर है जो आउटपुट देगा -

User-Add - 1
Blog-Delete - 64

यदि हम मौसम की जांच करना चाहते हैं तो किसी विशेष उपयोगकर्ता के पास उपयोगकर्ता-संपादन अनुमति है या नहीं-

  SELECT * FROM `user` 
     WHERE role & (select bit from permission where name='user-edit')

आउटपुट = कोई पंक्तियाँ नहीं।

आप यह भी देख सकते हैं: http://goo.gl/ATnj6j


और अगर 100, जैसे कई हैं, तो हम क्या करेंगे?
ypercube y 14

2
आपने 3 समान उत्तर पोस्ट किए हैं - विभिन्न प्रश्नों के लिए! -, सभी आज कुछ ही मिनटों के साथ अलग पोस्ट। यह अच्छा अभ्यास नहीं है। यदि आपको लगता है कि प्रश्न समान या समान हैं, तो आप उन्हें डुप्लिकेट के रूप में बंद करने के लिए वोट कर सकते हैं (या उन्हें बंद करें यदि आपके पास समापन के लिए वोट करने के लिए प्रतिष्ठा नहीं है)।
ypercube y

कृपया अपना लिंक भी संपादित करें और बताएं कि इसमें क्या है (अधिक विवरण, क्या यह आपका ब्लॉग है या किसी और का? आदि?)
ypercube14

कृपया एक ही उत्तर को कॉपी और पेस्ट न करें, इसे पुराने प्रश्नों के एक समूह में छिड़क दें। यदि वे प्रश्न समान हैं, तो उन्हें डुप्लिकेट के रूप में चिह्नित करें।
हारून बर्ट्रेंड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.