मेरे पास एक नर्तक वेब एप्लिकेशन है जो भाग वेब साइट और भाग वेब सेवा है; मेरे आवेदन पर कुछ मार्ग पर उनके लिए लेख होना चाहिए।पर्ल डांसर ऑथ समाधान जो एपीआई कुंजी का समर्थन करता है?
मुझे डांसर वेब ऐप के लिए मिले सभी ऑथ समाधानों को लॉगिन पृष्ठ पर पुनर्निर्देशन की आवश्यकता होती है; जबकि यह इंटरैक्टिव उपयोग के लिए ठीक है, यह एक आराम से वेब सेवा के लिए इष्टतम नहीं है।
क्या कोई औथ समाधान है जो एपीआई कुंजी की तरह कुछ करने की अनुमति देगा?
आपको इसे बनाने के लिए Dancer::Plugin::Auth::Extensible पर देखना चाहिए था। प्रत्येक अनुरोध में प्रमाण पत्र भेजने का सबसे आसान तरीका। ग्राहक पर, आप इस तरह अपने बाकी सेवा को फोन करता हूँ सकता है:
$ua->post('http://example.com/rest/getStuff?cred=foobar1234567, $search_criteria);
आप इसे इस तरह करते हैं, तो आप एक कुकी प्रदान कर सकता है, लेकिन आप की जरूरत नहीं है, और ग्राहक जरूरी की जरूरत नहीं होगी कुकी के बारे में परवाह है।
संपादित करें: यदि आप मूल प्रमाणीकरण चाहते हैं, तो Plack::Builder पर एक नज़र डालें। आप कुछ अनुरोधों के लिए लेख जोड़ने के लिए इसका उपयोग कर सकते हैं।
मैंने उस मॉड्यूल के बारे में लेखक से बात की; यह सभी अनुरोधों के साथ/लॉगिन फॉर्म पर रीडायरेक्ट करने का प्रयास करता है (जो आराम से वेब सेवाओं के साथ आसानी से काम नहीं करेगा)। – Blaskovicz
मुझे एपीआई कुंजी के बारे में बहुत कुछ पता नहीं है इसलिए दुर्भाग्यवश आपकी मदद नहीं कर सकता है। डांसर :: कुकबुक में उल्लिखित प्रमाणीकरण दृष्टिकोण प्रमाणीकरण के लिए वेब सेवा की तरह एक सरल आरईएसटी प्रदान करता है और नर्तक सत्र में प्रमाणीकरण विवरण संग्रहीत करता है। मैं अपने आरईएसटी आधारित क्लाइंट/सर्वर एप के साथ इस तरह की रणनीति का सफलतापूर्वक उपयोग कर रहा हूं। इसके बारे में जागरूक होने की एक महत्वपूर्ण बात यह है कि आपके क्लाइंट सत्र कुकीज़ पर पकड़ने में सक्षम होना चाहिए और प्रमाणीकरण के बाद अनुरोध हेडर में इन्हें वापस प्रदान करना चाहिए। अगर आप अधिक जानकारी चाहते हैं तो मुझे बताएं। –
मैंने सोचा कि सत्र/कुकीज़ का उपयोग करके REST के सिद्धांतों का उल्लंघन किया गया है ... – Blaskovicz
मुझे लगता है कि यह आरईएसटी के सिद्धांतों को देखता है। एक सिद्धांत स्टेटलेस सेवाओं को बनाना है और हां - सत्रों का उपयोग करके इसका उल्लंघन होता है। हालांकि, यदि आप स्थापित इंटरनेट प्रौद्योगिकियों के व्यावहारिक उपयोग के रूप में एक आरईएसटी सिद्धांत देखते हैं तो सत्र और कुकीज़ अधिक समझ में आता है। एक सहकर्मी द्वारा मुझे सुझाए गए एक समान दृष्टिकोण अनुरोध हेडर में उपयोगकर्ता नाम और पासवर्ड हैश पास करना है। फिर आप डांसर का उपयोग कर पहले ट्रिगर में उस हेडर जानकारी को संभाल सकते हैं। यह एक स्टेटलेस दृष्टिकोण है जो कुकीज़ पर भरोसा नहीं करता है - लेकिन प्रमाणीकृत सेवाओं के परीक्षण को जटिल बना सकता है। –