2012-02-10 13 views
16

उदाहरण के लिए मैं, दस्तावेज ए, बी, सी उपयोगकर्ता 1 केवल दस्तावेज एक को देखने के लिए सक्षम होना चाहिए है बी उपयोगकर्ता 2 केवल दस्तावेज़ सी को देखने के लिए सक्षम होना चाहिए क्या यह संभव है मेटाडेटा द्वारा फ़िल्टर किए बिना एसओएलआर में ऐसा करने के लिए? अगर मैं मेटाडेटा फ़िल्टर का उपयोग करता हूं, हर बार सही परिवर्तनों तक पहुंच होती है, तो मुझे रीइंडेक्स करना होगा।SOLR अनुमतियां/छनन परिणाम पहुँच अधिकार के आधार पर

[अद्यतन 2012/02/14] दुर्भाग्य से, ग्राहक के मामले में, परिवर्तन अक्सर होता है। डेटा गोपनीय है और आमतौर पर केवल उन मालिकों द्वारा प्रबंधित किया जाता है जो आंतरिक उपयोगकर्ता हैं। फिर विशिष्ट मामला यह है कि उन्हें उन दस्तावेज़ों को कुछ बाहरी उपयोगकर्ताओं को साझा करने और उन उपयोगकर्ताओं के लिए पहुंच स्तर निर्दिष्ट करने में सक्षम होना चाहिए। और इस समय के सबसे अधिक का सहारा काम है, और न समय

से आगे

उत्तर

9

मैं होगा पहचान दस्तावेज़ मेटाडाटा के रूप में (हाँ, इसके बहुवचन) का उपयोग भूमिकाओं भंडारण सुझाव देते हैं। यहां आवश्यक फ़ील्ड access_roles एक पहलू-सक्षम बहु-मूल्यवान स्ट्रिंग फ़ील्ड है।

Doc1: access_roles:[user_jane, manager_vienna] // Jane and the Vienna branch manager may see it 
Doc2: access_roles:[user_john, manager_vienna, special_team] // Jane, the Vienna branch manager and a member of special team may see it 

उपयोगकर्ता दस्तावेज़ के मालिक एक डिफ़ॉल्ट उस दस्तावेज़ के लिए पहुँच भूमिका है।

एक दस्तावेज़ के लिए उपयोग भूमिकाओं बदलने के लिए आपको access_roles संपादित करें।


जेन जब खोज करता है, पहुँच भूमिकाओं वह क्वेरी का हिस्सा हो जाएगा के अंतर्गत आता है। सोलर केवल उन दस्तावेज़ों को पुनर्प्राप्त करेगा जो उपयोगकर्ता की पहुंच भूमिका से मेल खाते हैं।

जेन (user_jane), वियना कार्यालय में प्रबंधक (manager_vienna) खोज करता है, उसकी खोज की तरह जाते हैं: जो सभी दस्तावेजों जो access_roles में user_janeयाmanager_vienna शामिल हासिल करेगा

q=mainquery 
&fq=access_roles:user_jane 
&fq=access_roles:manager_vienna 
&facet=on 
&facet.field=access_roles 

; Doc1 और Doc2

जब बॉब, (user_bob), एक विशेष टीम के सदस्य (specia_team) खोज करता है,

q=mainquery 
&fq=access_roles:user_bob 
&fq=access_roles:special_team 
&facet=on 
&facet.field=access_roles 

जो उसके लिए Doc2 को हासिल करेगा।

प्रश्नों से http://wiki.apache.org/solr/SimpleFacetParameters#Multi-Select_Faceting_and_LocalParams

+0

इस दृष्टिकोण का अर्थ है कि जब मुझे एक्सेस भूमिकाओं में कोई परिवर्तन होता है तो मुझे रीइंडेक्स करना होगा? इससे बचने के लिए कोई मतलब है? – Manny

+0

जब आप ** दस्तावेज़ ** की पहुंच भूमिका को बदलना चाहते हैं, तो आपको रीइंडेक्स करना होगा, दस्तावेज़ की किस तरह की पहुंच भूमिका एक्सेस कर सकती है। यह ** प्रश्न ** है जो प्रत्येक उपयोगकर्ता के लिए अलग है। – aitchnyu

+0

उस – aitchnyu

1

कोई Solr के लिए तंत्र है कि मुझे लगता है कि आप के बारे में पता मेटाडाटा में अधिकार को बनाए रखने के बिना दस्तावेजों तक पहुंच को नियंत्रित करने की अनुमति देगा कर रहा हूँ में निर्माण कर रहे हैं अनुकूलित। Aitchnyu द्वारा उल्लिखित दृष्टिकोण उचित लगता है यदि आप इसे एक वास्तविक भूमिका स्तर रखते हैं और किसी दस्तावेज़ को उपयोगकर्ता विशिष्ट अनुमतियां असाइन नहीं करते हैं। इस तरह आप उपयोगकर्ताओं को भूमिका निभा सकते हैं और इससे उन्हें सूचकांक में दस्तावेज़ देखने की क्षमता मिल जाएगी। अनुमोदित है कि भूमिकाओं में बदलाव होने पर आपको अभी भी दस्तावेजों को पुन: प्रस्तुत करने की आवश्यकता होगी, लेकिन उम्मीद है कि आप समय के आगे की आवश्यक भूमिकाओं की पहचान कर सकते हैं और लगातार पुनर्विक्रय की आवश्यकता को कम कर सकते हैं।

+0

दस्तावेज़ का मालिक होने वाले उपयोगकर्ता को उस दस्तावेज़ के लिए ** डिफ़ॉल्ट ** पहुंच भूमिका निर्धारित की जानी चाहिए। मैंने इसका जवाब स्पष्ट रूप से इसका अर्थ दिया। – aitchnyu

+0

दुर्भाग्यवश, ग्राहक के मामले में, परिवर्तन अक्सर होता है। डेटा गोपनीय है और आमतौर पर केवल उन मालिकों द्वारा प्रबंधित किया जाता है जो आंतरिक उपयोगकर्ता हैं। फिर विशिष्ट मामला यह है कि उन्हें उन दस्तावेज़ों को कुछ बाहरी उपयोगकर्ताओं को साझा करने और उन उपयोगकर्ताओं के लिए पहुंच स्तर निर्दिष्ट करने में सक्षम होना चाहिए। और ज्यादातर समय यह एक कार्य कार्य है, और समय से पहले पहचाना नहीं गया है। लेकिन स्पष्टीकरण – Manny

3

मुझे लगता है कि मेरी दृष्टिकोण @ aitchnyu का जवाब करने के समान होगा। हालांकि मैं मेटा डेटा में व्यक्तिगत उपयोगकर्ताओं का उपयोग नहीं करता। यदि आप प्रत्येक दस्तावेज़ के लिए समूह बनाते हैं, तो आपको कम से कम सुरक्षा कारण के लिए रीइंडेक्स करना होगा।

दिए गए दस्तावेज़ के लिए, आप access_roles हो सकता है: group_1, group_3

इस तरह, group_1 और group_3 हमेशा दस्तावेज़ के अधिकार हैं। हालांकि, मैं बदल सकता हूं कि प्रत्येक उपयोगकर्ता किस समूह से संबंधित है और तदनुसार क्वेरी समायोजित करता है।

जब क्वेरी उत्पन्न होती है, तो यह हमेशा उपयोगकर्ता के समूह की क्वेरी के हिस्से के रूप में गुजरती है। मैं group_1 और group_2 के हैं, मेरी क्वेरी इस तरह दिखेगा:

q=mainquery 
&fq=access_roles:group_1 
&fq=access_roles:group_2 

के बाद से समूह गतिशील क्वेरी में उत्पन्न कर रहे हैं, मैं बस एक उपयोगकर्ता समूह से, हटाने, और जब एक नई क्वेरी जारी किया जाता है वे क्वेरी में हटाए गए समूह को अब शामिल नहीं किया जाएगा।

q=mainquery 
&fq=access_roles:group_2 

सभी दस्तावेजों है कि समूह 1 की आवश्यकता नहीं रह गया उपयोगकर्ता के लिए सुलभ हो जाएगा: तो group_1 से उपयोगकर्ता को हटाने के नए इस तरह एक प्रश्न बन जाएगा।

यह अधिकांश वास्तविक समय में किए जाने वाले परिवर्तनों को दस्तावेजों को पुनर्निर्मित करने की आवश्यकता को बाहर करने के लिए अनुमति देता है। सुरक्षा कारणों से आपको पुनर्विचार करना एकमात्र कारण यह है कि यदि आपने फैसला किया है कि किसी विशेष समूह को अब किसी दस्तावेज़ तक पहुंच नहीं होनी चाहिए।

कई वास्तविक दुनिया परिदृश्यों में, यह अपेक्षाकृत असामान्य घटना होनी चाहिए। ऐसा लगता है कि मानव संसाधन विभाग हमेशा मानव संसाधन विभाग के लिए उपलब्ध होंगे, हालांकि एक विशिष्ट उपयोगकर्ता हमेशा मानव संसाधन समूह का हिस्सा नहीं हो सकता है।

उम्मीद है कि मदद करता है।

+0

क्या होगा यदि मुझे दस्तावेज़ ए को किसी बाहरी उपयोगकर्ता को साझा करने की आवश्यकता है, और दस्तावेज़ बी को किसी अन्य बाहरी उपयोगकर्ता को और इसी तरह से करना है। यह हमारे लिए एक आम मामला है। – Manny

+2

मैं हल्द्रिच 9 8 से सहमत हूं। अपने दृष्टिकोण के लिए नींव पढ़ने के लिए आरबीएसी देखें: http://en.wikipedia.org/wiki/Role-based_access_control और, आरबीएसी दृष्टिकोण के आधार पर, टाई-आरबीएसी देखें: सोशल नेटवर्क पर आरबीएसी का एक आवेदन (http://w2spconf.com/2011/papers/rbacSocialNet.pdf) @manny साझाकरण प्रश्न के बारे में –

2

ध्यान रखें कि तेजी से खोज की सुविधा के लिए सोलर शुद्ध टेक्स्ट आधारित सर्च इंजन, इंडेक्सिंग सिस्टम है, आपको आरडीएमएस शैली क्षमताओं की अपेक्षा नहीं करनी चाहिए। सोलर अनुक्रमित दस्तावेजों के लिए सुरक्षा प्रदान नहीं करता है, यदि आप चाहें तो आपको ऐसा कार्यान्वयन लिखना होगा। उस स्थिति में आपके पास दो विकल्प हैं। 1) बस सोलर में दस्तावेज़ों को इंडेक्स करें और आरडीबीएमएस में प्राधिकरण विवरण रखें। अपनी खोज के लिए क्वेरी पूछताछ करें और वापस लौटे गए परिणामों को इकट्ठा करें.अब उपयोगकर्ता द्वारा उनके पास पहुंच है या नहीं, यह देखने के लिए सौर द्वारा लौटाए गए दस्तावेज़ आईडी के लिए डीबी को एक और क्वेरी आग लगाना या नहीं। उन दस्तावेज़ों को फ़िल्टर करें जिन पर उपयोगकर्ता को कार्रवाई में कोई पहुंच नहीं है। आप कर चुके हैं! लेकिन वास्तव में, आपकी समस्या केवल यहां से शुरू होती है। मान लीजिए, क्या होगा अगर सोलर द्वारा लौटाए गए सभी परिणाम फ़िल्टर किए जाएंगे? (मान लें कि आप एक समय में सभी दस्तावेजों तक नहीं पहुंच रहे हैं, इसका मतलब है कि आप केवल सोलर परिणाम सेट से शीर्ष 1000 परिणामों को पुनर्प्राप्त कर रहे हैं, अन्यथा आपको तेज़ खोज नहीं मिल सकती है) आपको परिणाम सेट के अगले समूह के लिए फिर से सोलर से पूछना होगा और फिर से करना होगा इन चरणों को तब तक प्रदर्शित करने के लिए पर्याप्त परिणाम प्राप्त नहीं होते हैं। 2) इसके लिए दूसरा दृष्टिकोण दस्तावेज के साथ प्राधिकरण मेटा डेटा को अनुक्रमणित करना है। जैसा कि एटचनायु ने समझाया है। लेकिन उपयोगकर्ता समूह और भूमिका विस्तार के साथ, बाहरी उपयोगकर्ता को दस्तावेज़ साझा करने के लिए आपकी क्वेरी का उत्तर देने के लिए, आप इन बाहरी उपयोगकर्ता को इंडेक्स करते हैं userid access_roles फ़ील्ड में या आप अपने स्कीमा 'access_user' में भी एक और फ़ील्ड जोड़ सकते हैं। अब आप अपने फ़िल्टर क्वेरी में access_user फ़ील्ड को शामिल करने के लिए बाहरी उपयोगकर्ता के साझाकरण के लिए खोज क्वेरी संशोधित कर सकते हैं।

q=mainquery 
&fq=access_roles:group_1 
&fq=access_user:externaluserid 

अब सबसे महत्वपूर्ण बात, एक अनुक्रमित करने के लिए अद्यतन अपने बंद पाठ्यक्रम थकाऊ काम documents.Well, लेकिन जैसे सावधान डिजाइन और async प्रसंस्करण solrs के साथ आंशिक दस्तावेज़ अद्यतन सुविधा के साथ (Solr 4.0 =>), तो आपको सोलर के साथ उचित रूप से अच्छा टीपीएस प्राप्त कर सकते हैं। यदि आप सोलर < 4 का उपयोग कर रहे हैं।0 आप खोज और अपडेट दोनों के लिए अलग-अलग सिस्टम रख सकते हैं और लोड बैलेंसर और मास्टर गुलाम प्रतिकृति रणनीतियों के पूर्ण उपयोग की देखभाल के साथ आप अपने चेहरे पर मुस्कान करेंगे!

3

आप सोलर के पोस्टफिल्टर का उपयोग करके अपने सुरक्षा मॉडल को कार्यान्वित कर सकते हैं। अधिक जानकारी के लिए http://searchhub.org/2012/02/22/custom-security-filtering-in-solr/

नोट: आपको शायद अपने पहुंच अधिकारों को कैश करना चाहिए अन्यथा प्रदर्शन भयानक होगा।

संबंधित मुद्दे