एचटीटीपी अनुरोधों में User-Agent या Content-Type जैसे हेडर शामिल होते हैं. ब्राउज़र से अटैच किए गए हेडर के अलावा, Android ऐप्लिकेशन EXTRA_HEADERS इंटेंट एक्सट्रा की मदद से, कुकी या रेफ़रर जैसे अतिरिक्त हेडर जोड़ सकते हैं. सुरक्षा से जुड़ी वजहों से, Chrome कुछ अतिरिक्त हेडर को फ़िल्टर करता है. यह इस बात पर निर्भर करता है कि इंटेंट को कैसे और कहां लॉन्च किया गया है.
क्रॉस-ऑरिजिन अनुरोधों के लिए, सुरक्षा की एक अतिरिक्त लेयर की ज़रूरत होती है, क्योंकि क्लाइंट और सर्वर, दोनों का मालिकाना हक एक ही पक्ष के पास नहीं होता. इस गाइड में, Chrome के कस्टम टैब के ज़रिए ऐसे अनुरोध लॉन्च करने के बारे में बताया गया है. जैसे, ब्राउज़र टैब में यूआरएल खोलने वाले ऐप्लिकेशन से लॉन्च किए गए इंटेंट. Chrome के 83 वर्शन तक, डेवलपर कस्टम टैब लॉन्च करते समय कोई भी हेडर जोड़ सकते थे. Chrome के 83 वर्शन से, approvelisted क्रॉस-ऑरिजिन हेडर को छोड़कर, सभी हेडर को फ़िल्टर करना शुरू कर दिया गया है. ऐसा इसलिए किया गया है, क्योंकि 'अनुमति वाली सूची' में शामिल नहीं होने वाले हेडर से सुरक्षा से जुड़ा जोखिम होता है. Chrome 86 से, क्रॉस-ऑरिजिन अनुरोधों में ऐसे हेडर अटैच किए जा सकते हैं जिन्हें अनुमति वाली सूची में शामिल नहीं किया गया है. ऐसा तब किया जा सकता है, जब सर्वर और क्लाइंट, डिजिटल एसेट लिंक का इस्तेमाल करके जुड़े हों. इस व्यवहार के बारे में खास जानकारी नीचे दी गई टेबल में दी गई है:
| Chrome का वर्शन | सीओआरएस हेडर की अनुमति है |
|---|---|
| Chrome 83 से पहले | approvelisted, non-approvelisted |
| Chrome 83 से Chrome 85 | approvelisted |
| Chrome 86 और उसके बाद के वर्शन में | approvelisted, non-approvelisted when a digital asset link is set up |
टेबल 1: अनुमति वाली सूची में शामिल नहीं किए गए सीओआरएस हेडर को फ़िल्टर करना.
इस लेख में, सर्वर और क्लाइंट के बीच पुष्टि किए गए कनेक्शन को सेट अप करने का तरीका बताया गया है. साथ ही, इस कनेक्शन का इस्तेमाल करके, अनुमति वाली सूची में शामिल और अनुमति वाली सूची में शामिल नहीं किए गए एचटीटीपी हेडर भेजने का तरीका भी बताया गया है. कोड के लिए, कस्टम टैब इंटेंट में अतिरिक्त हेडर जोड़ना पर जाएं.
बैकग्राउंड
अनुमति वाले बनाम अनुमति नहीं वाले सीओआरएस रिक्वेस्ट हेडर
क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) की मदद से, एक ऑरिजिन का वेब ऐप्लिकेशन किसी दूसरे ऑरिजिन के रिसॉर्स का अनुरोध कर सकता है. CORS-approvelisted हेडर की सूची, एचटीएमएल स्टैंडर्ड में रखी जाती है. अनुमति वाली सूची में शामिल हेडर के उदाहरण, अगली टेबल में दिए गए हैं:
| हेडर | जानकारी |
|---|---|
| accept-language | उन नैचुरल लैंग्वेज का विज्ञापन दिखाता है जिन्हें क्लाइंट समझता है |
| content-language | मौजूदा ऑडियंस के लिए इस्तेमाल की जाने वाली भाषा की जानकारी देता है |
| content-type | संसाधन के मीडिया टाइप के बारे में बताता है |
टेबल 2.: अनुमति वाली सूची में शामिल सीओआरएस हेडर का उदाहरण.
अनुमति वाली सूची में शामिल हेडर को सुरक्षित माना जाता है, क्योंकि इनमें उपयोगकर्ता की संवेदनशील जानकारी शामिल नहीं होती. साथ ही, इनसे सर्वर को नुकसान पहुंचाने वाली कार्रवाइयां करने की संभावना कम होती है.
अनुमति वाली सूची में शामिल नहीं किए गए हेडर के उदाहरण, नीचे दी गई टेबल में दिए गए हैं:
| हेडर | जानकारी |
|---|---|
| bearer-token | सर्वर पर क्लाइंट की पुष्टि करता है |
| 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-browser-helper GitHub डेटा स्टोर करने की जगह देखें.
खास जानकारी
इस गाइड में, कस्टम टैब के सीओआरएस अनुरोधों में मनमुताबिक हेडर जोड़ने का तरीका बताया गया है. अनुमति वाले हेडर, कस्टम टैब के हर सीओआरएस अनुरोध में अटैच किए जा सकते हैं. अनुमति वाली सूची में शामिल नहीं किए गए हेडर को आम तौर पर, सीओआरएस अनुरोधों में असुरक्षित माना जाता है. साथ ही, Chrome उन्हें डिफ़ॉल्ट रूप से फ़िल्टर करता है. इन्हें सिर्फ़ एक ही ऑरिजिन के क्लाइंट और सर्वर के लिए अटैच किया जा सकता है. साथ ही, इनकी पुष्टि डिजिटल एसेट के लिंक से की जानी चाहिए.