बेसिक HTTP और बियरर टोकन ऑथेंटिकेशन

Question

मैं वर्तमान में एक REST-API विकसित कर रहा हूं, जो विकास के वातावरण के लिए HTTP-Basic संरक्षित है। जैसा कि वास्तविक प्रमाणीकरण एक टोकन के माध्यम से किया जाता है, मैं अभी भी यह पता लगाने की कोशिश कर रहा हूं कि दो प्राधिकरण हेडर कैसे भेजें।

मैंने यह एक कोशिश की है:

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Authorization: Bearer mytoken123"

मैं उदाहरण के लिए अपने आईपी के लिए HTTP-प्रमाणीकरण को अक्षम कर सकता हूं लेकिन जैसा कि मैं आमतौर पर गतिशील आईपी के साथ विभिन्न वातावरणों में काम करता हूं, यह एक अच्छा समाधान नहीं है। तो क्या मुझे कुछ याद आ रहा है?

Comments

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

— अज़नेक

आप कभी इसका पता लगाते हैं? मैं

— एडम वेट

नमस्ते एडम, दुर्भाग्य से नहीं। मैंने अब प्रमाणीकरण प्राधिकारी द्वारा मेरे प्राधिकारी हैडर को टोकन के लिए "एक्स-ऑर्टिकल" में बदलकर काम किया है जो एक मानक हेडर नहीं है।

— अज़नेक

मेरा nginx सर्वर 2 प्राधिकरण हेडर भी स्वीकार नहीं करेगा। यह एक रिटर्न 400 Bad request। बेवकूफ।

— रुडी

अपने एपीआई टोकन के लिए कस्टम हेडर का उपयोग करने में क्या गलत है? मैं यह नहीं देखता कि यहां के लोग अपने विकास / मंचन को चुभने वाली नज़रों से दूर रखने के लिए HTTP बेसिक ऑथेन्ट का उपयोग करके "छटपटा" क्यों रहे हैं।

— सुनील डी।

Answer 1

मूल प्रमाणीकरण पर जोर देने के लिए इसे आज़माएं:

curl -i http://username:[e-mail]/api/users -H "Authorization: Bearer mytoken123"
               ^^^^^^^^^^^^^^^^^^

यदि ऊपर कोई काम नहीं करता है, तो आपको इससे कोई लेना-देना नहीं है। तो निम्नलिखित विकल्पों का प्रयास करें।

आप एक अन्य नाम के तहत टोकन पास कर सकते हैं। क्योंकि आप अपने एप्लिकेशन से प्राधिकरण संभाल रहे हैं। तो आप इस विशेष उद्देश्य के लिए आसानी से इस लचीलेपन का उपयोग कर सकते हैं।

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Application-Authorization: mytoken123"

सूचना मैंने हेडर को बदल दिया है Application-Authorization। तो अपने आवेदन से उस हेडर के नीचे एक टोकन को पकड़ें और आपको जो करने की आवश्यकता है उसे संसाधित करें।

एक और चीज जो आप कर सकते हैं, tokenवह है POSTमापदंडों से गुजरना और सर्वर की तरफ से पैरामीटर की वैल्यू को पकड़ना। उदाहरण के लिए कर्ल पोस्ट पैरामीटर के साथ टोकन गुजरना:

-d "auth-token=mytoken123"

Comments

हैलो सबुज, मुद्दा यह नहीं है कि आप उपयोगकर्ता नाम और पासवर्ड कैसे पारित करते हैं, लेकिन कई प्राधिकरण हेडर सिर्फ काम नहीं करते हैं। चश्मा ( ietf.org/rfc/rfc2617.txt ) देखकर मैं देख सकता हूं कि यह संभव होना चाहिए। लेकिन जैसा कि कहा गया है "" उपयोगकर्ता एजेंट MUST को उस चुनौती के आधार पर सबसे मजबूत ऑर्ट-स्कीम के साथ चुनौतियों में से एक का उपयोग करने के लिए चुनता है और उपयोगकर्ता से क्रेडेंशियल्स का अनुरोध करता है। " जब आप गैर-मानक आर्किटेक्चर के साथ व्यवहार करते हैं, तो एक गैर-मानक हेडर के लिए टोकन, जो ठीक है।

— Azngeek

@Azngeek कर्ल जब आप कार्य करते हैं तो दोनों प्राधिकरण हेडर भेजते हैं। आपको इसे अपने सर्वर के अंत से संभालने की आवश्यकता है। बस अपने कर्ल कमांड को दोनों हेडर के साथ -vपरम के साथ चलाएं । आप पाएंगे कि इसका Authorization: Basic Ym9zY236Ym9zY28=, Authorization: Bearer mytoken123अनुरोध अनुरोध हेडर पर भेजा जा रहा है । अपने सर्वर के अंत से, यदि आप जांच करते हैं, तो आप पाएंगे कि आपके पास प्राधिकरण शीर्षलेख है जैसे Authorization: Basic Ym9zY236Ym9zY28=, Bearer mytoken123अल्पविराम द्वारा अलग किया गया। इसलिए, हालांकि मुझे आपको वैकल्पिक सुझाव देना चाहिए।

— सबुज हसन

Answer 2

मानक ( https://tools.ietf.org/html/rfc6750 ) का कहना है कि आप इसका उपयोग कर सकते हैं:

• प्रपत्र-एन्कोडेड बॉडी पैरामीटर: प्राधिकरण: बियरर mytoken123
• URI क्वेरी पैरामीटर: access_token = mytoken123

इसलिए यूआरआई के साथ कई बियरर टोकन पास करना संभव है, लेकिन ऐसा करना हतोत्साहित करता है (मानक में धारा 5 देखें)।

Answer 3

यदि आप बीच में nginx जैसे एक रिवर्स प्रॉक्सी का उपयोग कर रहे हैं, तो आप एक कस्टम टोकन को परिभाषित कर सकते हैं, जैसे कि X-API-Token।

नगीनक्स में आप इसे अपस्ट्रीम प्रॉक्सी (आपकी बाकी एपीआई) के लिए फिर से लिखेंगे।

proxy_set_header Authorization $http_x_api_token;

... जबकि nginx HTTP ऑर्थ की जांच करने के लिए मूल प्राधिकरण हेडर का उपयोग कर सकता है।

Answer 4

मुझे एक समान समस्या थी - डिवाइस पर डिवाइस और उपयोगकर्ता को प्रमाणित करें। मैंने एक Cookieहेडर के साथ एक Authorization: Bearer...हेडर का उपयोग किया ।

Comments

स्पष्ट नहीं है कि नीचे क्यों। मैं इस समस्या से संबंधित समस्या के उत्तर की खोज में आया था - यह है कि मैंने इसे कैसे हल किया। Cookieशीर्ष लेख पहले से ही अक्सर प्रमाणीकरण के लिए प्रयोग किया जाता है।

— Iiridayn

Answer 5

कर्ल - कन्या

कर्ल को प्रमाणीकरण विधि का पता लगाने के लिए कहता है, और सबसे सुरक्षित साइट का उपयोग करता है जो समर्थन करने का दावा करता है। यह पहले एक अनुरोध करने और प्रतिक्रिया की जांच करने वाले हेडर द्वारा किया जाता है, इस प्रकार संभवतः एक अतिरिक्त नेटवर्क राउंड-ट्रिप को प्रेरित करता है। इसका उपयोग एक विशिष्ट प्रमाणीकरण विधि को सेट करने के बजाय किया जाता है, जिसे आप --basic, --digest, --ntlm और --negotiate के साथ कर सकते हैं।

Answer 6

विकास सर्वर पर एपीआई का परीक्षण करने के लिए एक और समाधान है।

• HTTP Basic Authenticationकेवल वेब मार्गों के लिए सेट करें
• सभी एपीआई मार्गों को प्रमाणीकरण से मुक्त छोड़ दें

इसके लिए वेब सर्वर कॉन्फ़िगरेशन nginxऔर Laravelऐसा होगा:

    location /api {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location / {
        try_files $uri $uri/ /index.php?$query_string;

        auth_basic "Enter password";
        auth_basic_user_file /path/to/.htpasswd;
    }

Authorization: Bearer वेब क्रॉलर और अन्य अवांछित आगंतुकों के खिलाफ विकास सर्वर का बचाव करने का काम करेगा।

Answer 7

नगनेक्स के साथ आप दोनों टोकन इस तरह भेज सकते हैं (भले ही यह मानक के खिलाफ हो):

Authorization: Basic basic-token,Bearer bearer-token

यह तब तक काम करता है जब तक कि मूल टोकन पहले - nginx सफलतापूर्वक इसे एप्लिकेशन सर्वर पर फॉरवर्ड कर देता है।

और फिर आपको यह सुनिश्चित करने की आवश्यकता है कि आपका एप्लिकेशन उपरोक्त स्ट्रिंग से बियरर को ठीक से निकाल सकता है।