ज़्यादा एचटीटीपी अनुरोध के हेडर जोड़ना

एचटीटीपी अनुरोधों में User-Agent या Content-Type जैसे हेडर होते हैं. Android ऐप्लिकेशन, ब्राउज़र की मदद से अटैच किए गए हेडर के अलावा, EXTRA_HEADERS इंटेंट के ज़रिए अतिरिक्त हेडर जोड़ सकते हैं. जैसे, कुकी या रेफ़रर. सुरक्षा की वजहों से, Chrome कुछ अतिरिक्त हेडर को इस आधार पर फ़िल्टर करता है कि इंटेंट कैसे और कहां लॉन्च किया गया है.

क्रॉस-ऑरिजिन अनुरोधों के लिए सुरक्षा की एक और लेयर ज़रूरी होती है, क्योंकि क्लाइंट और सर्वर का मालिकाना हक एक ही पक्ष के पास नहीं होता. इस गाइड में, Chrome के कस्टम टैब से इस तरह के अनुरोधों को लॉन्च करने के बारे में जानकारी दी गई है. जैसे, उन ऐप्लिकेशन से लॉन्च किए गए इंटेंट जो ब्राउज़र टैब में यूआरएल खोलते हैं. Chrome 83 तक, डेवलपर कस्टम टैब लॉन्च करते समय कोई भी हेडर जोड़ सकते थे. वर्शन 83 के बाद से, Chrome ने मंज़ूरी दिए गए क्रॉस-ऑरिजिन हेडर को छोड़कर सभी को फ़िल्टर करना शुरू कर दिया है. ऐसा इसलिए, क्योंकि ऐसे हेडर सुरक्षा के लिए जोखिम पैदा करते थे जिन्हें अनुमति नहीं मिली है. जब सर्वर और क्लाइंट डिजिटल एसेट लिंक का इस्तेमाल करके एक-दूसरे से जुड़े होते हैं, तो Chrome 86 और उसके बाद के वर्शन में, क्रॉस-ऑरिजिन अनुरोधों में उन हेडर को अटैच किया जा सकता है जिनकी अनुमति नहीं है. इस व्यवहार की खास जानकारी इस टेबल में दी गई है:

Chrome का वर्शन	सीओआरएस हेडर की अनुमति है
Chrome 83 से पहले के वर्शन	मंज़ूरी वाली सूची में शामिल, बिना मंज़ूरी वाला
Chrome 83 से Chrome 85	अनुमति वाली सूची में शामिल है
Chrome 86 के बाद के वर्शन	जब डिजिटल ऐसेट लिंक सेट अप किया जाता है, तब मंज़ूरी नहीं मिलती, लेकिन मंज़ूरी नहीं मिलती

टेबल 1.: उन सीओआरएस हेडर को फ़िल्टर करना जिन्हें अनुमति नहीं मिली है.

इस लेख में, सर्वर और क्लाइंट के बीच पुष्टि किए गए कनेक्शन को सेट अप करने का तरीका बताया गया है. साथ ही, इसका इस्तेमाल अनुमति वाली सूची और बिना अनुमति वाले एचटीटीपी हेडर को भेजने के लिए किया जा सकता है. कोड के लिए, कस्टम टैब इंटेंट में अतिरिक्त हेडर जोड़ना पर जाएं.

बैकग्राउंड

जिन सीओआरएस अनुरोध को स्वीकार किया गया है उनकी तुलना में स्वीकार नहीं किए गए सीओआरएस अनुरोध के हेडर

क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) की मदद से, कोई वेब ऐप्लिकेशन किसी एक ऑरिजिन के वेब ऐप्लिकेशन को, अलग-अलग ऑरिजिन के रिसॉर्स के लिए अनुरोध कर सकता है. सीओआरएस की अनुमति वाले हेडर की सूची को एचटीएमएल स्टैंडर्ड में रखा जाता है. अगली टेबल में, अनुमति वाले हेडर के उदाहरण दिखाए गए हैं:

हेडर	Description
स्वीकार की जाने वाली भाषा	ऐसी आम भाषाओं के विज्ञापन दिखाता है जो क्लाइंट को समझ आती हैं
कॉन्टेंट की भाषा	इससे मौजूदा ऑडियंस की भाषा के बारे में पता चलता है
कॉन्टेंट-टाइप	संसाधन के मीडिया प्रकार को दर्शाता है

टेबल 2.: अनुमति वाले सीओआरएस हेडर का उदाहरण.

अनुमति वाली सूची में शामिल हेडर सुरक्षित माने जाते हैं, क्योंकि इनमें उपयोगकर्ता की संवेदनशील जानकारी नहीं होती है. साथ ही, सर्वर को नुकसान पहुंचाने वाली कार्रवाइयां करने की संभावना कम होती है.

इस टेबल में उन हेडर के उदाहरण दिए गए हैं जिन्हें अनुमति नहीं दी गई है:

हेडर	Description
बेयर-टोकन	सर्वर पर क्लाइंट की पुष्टि करता है
origin	अनुरोध की शुरुआत की जगह के बारे में बताता है
कुकी	इसमें सर्वर द्वारा सेट कुकी शामिल हैं

टेबल 3.: ऐसे सीओआरएस हेडर का उदाहरण जिन्हें अनुमति नहीं दी गई है.

एचटीएमएल स्टैंडर्ड और सर्वर यह मानकर चलते हैं कि क्रॉस-ऑरिजिन अनुरोधों में सिर्फ़ मंज़ूरी वाली सूची वाले हेडर शामिल होते हैं. ऐसे हेडर को सीओआरएस अनुरोधों में अटैच नहीं किया जाता है. क्रॉस-ऑरिजिन डोमेन से अनुमति नहीं वाले हेडर भेजने से, तीसरे पक्ष के ऐप्लिकेशन ऐसे हेडर बना सकते हैं जो उपयोगकर्ता की उन कुकी का गलत इस्तेमाल करते हैं जिन्हें Chrome या किसी दूसरे ब्राउज़र ने स्टोर किया है और अनुरोधों में अटैच किया है. कुकी, सर्वर से किए गए नुकसान पहुंचाने वाले लेन-देन की पुष्टि कर सकती हैं. अगर ऐसा नहीं किया जाता है, तो ये लेन-देन मुमकिन नहीं होते हैं.

सीओआरएस से अनुमति पा चुके हेडर, कस्टम टैब अनुरोधों में अटैच किए जा रहे हैं

कस्टम टैब, पसंद के मुताबिक बनाए गए ब्राउज़र टैब में वेब पेजों को लॉन्च करने का एक खास तरीका है. CustomTabsIntent.Builder() का इस्तेमाल करके, कस्टम टैब से जुड़े इंटेंट बनाए जा सकते हैं. Browser.EXTRA_HEADERS फ़्लैग वाले Bundle का इस्तेमाल करके, इन इंटेंट के लिए हेडर भी अटैच किए जा सकते हैं:

CustomTabsIntent intent = new CustomTabsIntent.Builder(session).build();

Bundle headers = new Bundle();
headers.putString("bearer-token", "Some token");
headers.putString("redirect-url", "Some redirect url");   
intent.intent.putExtra(Browser.EXTRA_HEADERS, headers);

intent.launchUrl(Activity.this, Uri.parse("http://www.google.com"));

हम कस्टम टैब के सीओआरएस अनुरोधों में, अनुमति वाले हेडर हमेशा अटैच कर सकते हैं. हालांकि, Chrome डिफ़ॉल्ट रूप से अनुमति नहीं वाले हेडर को फ़िल्टर करता है. हालांकि, अन्य ब्राउज़र का व्यवहार अलग हो सकता है. हालांकि, डेवलपर को यह मानकर चलना चाहिए कि वे हेडर सामान्य तौर पर ब्लॉक कर दिए जाएंगे जिन्हें अनुमति नहीं मिली है.

कस्टम टैब में अनुमति नहीं दिए गए हेडर को शामिल करने का एक तरीका यह है कि पहले किसी डिजिटल ऐक्सेस लिंक का इस्तेमाल करके क्रॉस-ऑरिजिन कनेक्शन की पुष्टि की जाए. अगले सेक्शन में, इन्हें सेट करने और ज़रूरी हेडर के साथ कस्टम टैब इंटेंट लॉन्च करने का तरीका बताया गया है.

कस्टम टैब इंटेंट में ज़्यादा हेडर जोड़ना

डिजिटल ऐसेट लिंक सेट अप करना

बिना अनुमति वाले हेडर को कस्टम टैब इंटेंट के ज़रिए भेजने की अनुमति देने के लिए, Android और वेब ऐप्लिकेशन के बीच एक डिजिटल एसेट लिंक सेट अप करना ज़रूरी है. यह इस बात की पुष्टि करेगा कि लेखक के पास दोनों ऐप्लिकेशन का मालिकाना हक है.

डिजिटल ऐसेट लिंक सेट अप करने के लिए, आधिकारिक गाइड देखें. लिंक के लिए, "delegate_permission/Common.use_as_origin"` का इस्तेमाल करना. इससे पता चलता है कि लिंक की पुष्टि होने के बाद, दोनों ऐप्लिकेशन एक ही ऑरिजिन से जुड़े होंगे.

ज़्यादा हेडर की मदद से कस्टम टैब इंटेंट बनाना

कस्टम टैब इंटेंट बनाने के कई तरीके हैं. लाइब्रेरी को बिल्ड डिपेंडेंसी में जोड़कर, androidX में उपलब्ध बिल्डर का इस्तेमाल किया जा सकता है:

MULTI_LINE_CODE_PLACEHOLDER_1

इंटेंट बनाएं और अतिरिक्त हेडर जोड़ें:

MULTI_LINE_CODE_PLACEHOLDER_2

ऐसेट लिंक की पुष्टि करने के लिए, कस्टम टैब कनेक्शन सेट अप करें

ऐप्लिकेशन और Chrome टैब के बीच CustomTabsSession सेट अप करने के लिए, कस्टम टैब कनेक्शन का इस्तेमाल किया जाता है. हमें सेशन की ज़रूरत है, ताकि यह पुष्टि की जा सके कि ऐप्लिकेशन और वेब ऐप्लिकेशन एक ही ऑरिजिन से हैं. पुष्टि की प्रोसेस सिर्फ़ तब पूरी होती है, जब डिजिटल ऐसेट लिंक सही तरीके से सेट अप किए गए हों.

आपको CustomTabsClient.warmup() पर कॉल करने का सुझाव दिया जाता है. यह ब्राउज़र ऐप्लिकेशन को बैकग्राउंड में पहले से शुरू करने और यूआरएल खोलने की प्रोसेस को तेज़ करने देता है.

MULTI_LINE_CODE_PLACEHOLDER_3

ऐसा कॉलबैक सेट अप करें जो पुष्टि के बाद इंटेंट लॉन्च करता हो

CustomTabsCallback को सेशन में पास किया गया. ऑरिजिन की पुष्टि होने के बाद, हमने पहले बनाए गए CustomTabsIntent को लॉन्च करने के लिए, onRelationshipValidationResult() को सेट अप किया है.

MULTI_LINE_CODE_PLACEHOLDER_4

कस्टम टैब के सेवा कनेक्शन को बाइंड करने की अनुमति दें

सेवा को बाइंड करने से सेवा लॉन्च हो जाएगी और कनेक्शन के onCustomTabsServiceConnected() को कॉल किया जाएगा. सेवा की शर्तों को सही तरीके से रद्द करना न भूलें. आम तौर पर, onStart() और onStop() गतिविधि लाइफ़साइकल वाले तरीकों में बाइंडिंग और अनबाइंडिंग की जाती है.

// Bind the custom tabs service connection.
// Call this in onStart()
CustomTabsClient.bindCustomTabsService(this,
    CustomTabsClient.getPackageName(MainActivity.this, null), connection);

// …
// Unbind the custom tabs service.
// Call this in onStop().
unbindService(connection);

डेमो ऐप्लिकेशन कोड

आपको कस्टम टैब सेवा के बारे में ज़्यादा जानकारी यहां मिल सकती है. काम करने वाले उदाहरण वाले ऐप्लिकेशन के लिए, android-ब्राउज़र-helper GitHub रिपॉज़िटरी देखें.

खास जानकारी

इस गाइड में, कस्टम टैब वाले सीओआरएस अनुरोधों में आर्बिट्रेरी हेडर जोड़ने का तरीका बताया गया है. अनुमति वाले हेडर हर कस्टम टैब के सीओआरएस अनुरोध से अटैच किए जा सकते हैं. आम तौर पर, अनुमति नहीं दिए गए हेडर को सीओआरएस अनुरोधों में असुरक्षित माना जाता है और Chrome उन्हें डिफ़ॉल्ट रूप से फ़िल्टर कर देता है. उन्हें अटैच करने की अनुमति सिर्फ़ एक ही ऑरिजिन के क्लाइंट और सर्वर के लिए है, जिनकी पुष्टि डिजिटल एसेट लिंक से की जाती है.