हमारे पास एक वेब एपीआई 2 ओडाटा वी 3 सेवा है जिसे हमें काफी जटिल प्रमाणीकरण को लागू करने की आवश्यकता है। हम अपने क्लाइंट कोड के भीतर ब्रीज़ का उपयोग कर रहे हैं और जब ब्रीज़ का ओडाटा वी 4 संस्करण जारी किया जाता है तो हम अपने एपीआई को ओडाटा वी 4 में अपग्रेड कर रहे हैं, इसलिए समाधान को ओडाटा संस्करणों दोनों पर काम करने में सक्षम होना चाहिए।ओडाटा वेबएपीआई 2 कॉम्प्लेक्स प्रमाणीकरण
यह चित्र इकाई मॉडल की तरह हम साथ काम कर रहे (माफ करना, एक छवि के लिए नहीं पर्याप्त प्रतिष्ठा अंक) की एक बहुत ही बुनियादी दृश्य देता है:
ServiceCompany
|
|
/|\
Manufacturer
|
|
/|\
Site
|
|
/|\
SiteArea -------
| |
| |
/|\ /|\
Equipment Instrument
|
|
/|\
Channel
एक SiteArea "OperatingFunction" की एक संपत्ति है - यह दिखाता है कि इस साइट क्षेत्र के स्थान पर विनिर्माण प्रक्रिया का कौन सा चरण होता है।
एक उपयोगकर्ता
- एक व्यक्ति निर्माता स्तर पर बैठे हो सकता है और उनके साइट डेटा
- एक व्यक्ति निर्माता स्तर पर बैठे के सभी का उपयोग किया है और कुछ की पहुंच है, लेकिन अपने SiteAreas के सभी, और इसलिए केवल उनके SiteArea डेटा
- एक व्यक्ति ServiceCompany स्तर जो कुछ निर्माताओं की पहुंच है पर बैठे, और कहा कि केवल उन निर्माताओं के भीतर कुछ साइटों में, और एक SiteArea की शायद केवल कुछ OperatingFunctions के उप-अनुभाग।
चैनल डेटा के लिए एक अनुरोध आएगा और हमें यह सुनिश्चित करने की आवश्यकता है कि व्यक्ति को केवल उस डेटा को वापस करने या अपडेट (अनुरोध प्रकार के आधार पर) को सुनिश्चित करने की आवश्यकता हो, जिसे व्यक्ति को प्रभावित करने की अनुमति है।
प्रारंभिक जांच के बाद इसे लागू करने के लिए स्पष्ट विकल्प QueryInterceptors और ChangeInterceptors के रूप में दिखाई दिया, जिसका अर्थ है कि हम अनुरोध के साथ भेजे गए दावों के आधार पर और फ़िल्टर वरीयताओं को जोड़ सकते हैं। हालांकि ऐसा लगता है कि क्वेरी/ChangeInterceptors WCF, नहीं WebAPI का हिस्सा हैं, और उस के शीर्ष पर वे v1-3 WCF OData कार्यान्वयन का ही हिस्सा हैं, अब तक OData v4 के लिए कोई बात नहीं है।
हम, ज़ाहिर है, फिल्टर कोड प्रत्येक विधि में लिख सकता है, लेकिन वास्तव में लगता है जैसे कि यह कुछ अनिवार्य रूप से एक क्रॉस कटिंग चिंता का विषय है कि लागू करने के लिए एक बुरा तरीका होगा।
हमने ईएफ 6 इंटरसेप्टर्स को देखा है लेकिन इस निष्कर्ष पर पहुंचे हैं कि वे ढेर से बहुत दूर हैं, आदर्श रूप में हम एसक्यूएल कमांड कोड से खुद से निपटना नहीं चाहते हैं।
हमने संक्षेप में विचार किया है कि हमें भूमिका/कार्य आधारित प्राधिकरण पैटर्न का उपयोग करना चाहिए और यह एक ठोस निष्कर्ष पर आ गया है कि यह हमारे लिए काम नहीं करेगा क्योंकि यह भविष्य के विकास के लिए बहुत ही सीमित है और हमारे स्केलिंग में काम नहीं करेगा योजना है।
अनिवार्य रूप से हम इस निष्कर्ष पर पहुंचे हैं कि हमें अपने स्वयं के क्वेरी इंटरसेप्टर एट्रिब्यूट को लागू करने की आवश्यकता है, लेकिन यह सोचने लायक है कि क्या हमने पहिया को फिर से शुरू करने से पहले कुछ याद किया है या नहीं।
धन्यवाद।
संपादित करें: मैं एक और विकल्प डेकोरेटर पैटर्न, हम एकता और उस के साथ प्रयोग कर रहे हैं कार्यक्षमता हम यह अपेक्षा करते जोड़ सकते हैं का उपयोग कर को देखने के लिए हो सकता है कि उल्लेख करना भूल गया: Unity Interception
हां एक कस्टम क्वेरी इंटरसेप्टर एट्रिब्यूट इस मामले में आगे बढ़ने का तरीका है, जो सभी परिदृश्यों को एक सहज तरीके से संभालने में मदद करेगा –