मुझे लगता है कि /api/controller/docId क्लाइंट आईडी और डॉकआईडी (मेरी वरीयता) का प्रतिनिधित्व करने के लिए शायद एक सबसे अच्छा विचार है या एक सरोगेट कुंजी का उपयोग करना है।
जब तक आपको कभी भी अन्य क्लाइंट संसाधनों को देखने की अनुमति नहीं दी जाती है, तो मैं इसे यूआरआई योजना से छिपाऊंगा, सबसे खराब रूप से इसे सूचना रिसाव माना जा सकता है क्योंकि यह क्लाइंट को प्रमाणित करता है और पता है कि वे वैसे भी हैं । यह एक ओवरहेड भी है यानी आपको अभी भी यूआरएल में क्लाइंट आईडी की जांच करनी होगी, अनुरोध के उपयोगकर्ता नाम और पासवर्ड पर मैप किया गया है, इसलिए आपको प्रत्येक अनुरोध पर क्लाइंट आईडी पुनर्प्राप्त करने की आवश्यकता है।
यदि आपने देखा कि अन्य बहु किरायेदार वातावरण कैसे काम करते हैं उदा। सेल्स फोर्स के आप देख सकते हैं कि उन्हें सुरक्षा तंत्र के माध्यम से ग्राहक का अनुमान लगाना चाहिए या प्रत्येक ऑब्जेक्ट/संसाधन के लिए एक अद्वितीय आईडी रखने के लिए भाग्यशाली हैं।
मैंने जो दृष्टिकोण देखा है वह क्लाइंट पहचानकर्ता (आमतौर पर किसी अन्य की सरोगेट कुंजी, अन्य उपयोगकर्ताओं को डीबी आईडी के उजागर होने से बचने के लिए) को यूआरएल की जड़ पर डालना है।/Api/{clientid}/नियंत्रक/डाक आईडी। एक बहु किरायेदार माहौल में प्रत्येक संसाधन शायद उस ग्राहक के लिए अद्वितीय परिभाषा द्वारा/है।
एक कारण कभी कभी इस दृष्टिकोण के लिए यह देखते हुए कि कैशिंग के साथ ग्राहक सहायता प्रति एक अनूठा यूआरएल होने .../api/{clientid}/नियंत्रक/डाक आईडी या/api/नियंत्रक/{clientid}/डाक आईडी
है बुनियादी प्रमाणीकरण
कुछ भी नहीं है अपने दृष्टिकोण के साथ गलत है लेकिन पर विचार के ऊपर एक संक्षिप्त नोट ... आप पासवर्ड और उपयोगकर्ता नाम मान्य जबकि क्लाइंट आईडी निकालते हैं और कि जोड़ने IPrinciple पर एक दावे के रूप में कर सकता है। कम से कम तब कोड में उपलब्ध है बिना किसी और डीबी देखो को खोजने के लिए (उस अनुरोध के जीवन के भीतर)।
एक कदम आगे जा रहे हैं ... एक दो चरण प्रमाणीकरण तंत्र पर विचार करें जहां एक टोकन जारी किया गया है (सही उपयोगकर्ता नाम और पासवर्ड का पालन करें) क्लाइंट आईडी के साथ वास्तव में दावा के रूप में टोकन में। इस तरह, टोकन के साथ बाद के अनुरोधों का मतलब है कि आपको जानकारी को प्रमाणित करने और पुनर्प्राप्त करने के लिए प्रत्येक अनुरोध के लिए डीबी को वापस कॉल करने की आवश्यकता नहीं होगी। OAuth वाहक टोकन http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html पर एक नजर डालें या अन्य तरीकों में से कुछ (उन पर हस्ताक्षर करने के लिए सुनिश्चित करें) ...
स्रोत
2012-12-07 11:39:47
मेरे पास समान स्थिति है। क्या आपने उपयोगकर्ता दावे के रूप में संग्रहीत किरायेदार आईडी (या पहुंच टोकन/प्रमाण-पत्रों के समान) माना है? मुझे लगता है कि यूआरआई के हिस्से के रूप में किरायेदार आदर्श है, लेकिन मौजूदा सॉफ्टवेयर पर लागू होने पर इसे और अधिक काम की आवश्यकता है। – bjornhol
@bjornhol यदि किरायेदार आईडी को यूआरएल में शामिल नहीं किया गया है तो यह स्थानीय कैशिंग को मुश्किल बनाता है क्योंकि मैं पूर्णांक का उपयोग करता हूं और पहचानकर्ताओं के लिए guids नहीं, इसलिए किरायेदारों के बीच संघर्ष हो सकते हैं। –