एचटीटीपी अनुरोधों में User-Agent या Content-Type जैसे हेडर शामिल होते हैं. ब्राउज़र से अटैच किए गए हेडर के अलावा, Android ऐप्लिकेशन EXTRA_HEADERS इंटेंट के हिसाब से कुकी या रेफ़रल जैसे दूसरे हेडर भी जोड़ सकते हैं. सुरक्षा के लिहाज़ से, Chrome कुछ अतिरिक्त हेडर को फ़िल्टर करता है. यह इस बात पर निर्भर करता है कि इंटेंट को कैसे और कहां लॉन्च किया गया है.
क्रॉस-ऑरिजिन अनुरोधों के लिए सुरक्षा की एक अतिरिक्त लेयर की ज़रूरत होती है, क्योंकि क्लाइंट और सर्वर का मालिकाना हक एक ही पक्ष के पास नहीं होता. इस गाइड में, Chrome के कस्टम टैब के ज़रिए ऐसे अनुरोध लॉन्च करने के बारे में बताया गया है. जैसे, ब्राउज़र टैब में यूआरएल खोलने वाले ऐप्लिकेशन से लॉन्च किए गए इंटेंट. Chrome के 83 वर्शन तक, डेवलपर कस्टम टैब लॉन्च करते समय कोई भी हेडर जोड़ सकते थे. वर्शन 83 और उसके बाद के वर्शन में, Chrome ने मंज़ूरी दिए गए क्रॉस-ऑरिजिन हेडर को छोड़कर, बाकी सभी को फ़िल्टर करना शुरू कर दिया है. ऐसा इसलिए है, क्योंकि अनुमति नहीं दिए गए हेडर की वजह से सुरक्षा से जुड़ा जोखिम हो सकता है. Chrome 86 से, क्रॉस-ऑरिजिन अनुरोधों में ऐसे हेडर अटैच किए जा सकते हैं जिन्हें अनुमति वाली सूची में शामिल नहीं किया गया है. ऐसा तब किया जा सकता है, जब सर्वर और क्लाइंट, डिजिटल एसेट लिंक का इस्तेमाल करके जुड़े हों. इस व्यवहार के बारे में खास जानकारी नीचे दी गई टेबल में दी गई है:
| Chrome का वर्शन | सीओआरएस हेडर की अनुमति है |
|---|---|
| Chrome 83 से पहले | approvelisted, non-approvelisted |
| Chrome 83 से Chrome 85 | approvelisted |
| Chrome 86 और उसके बाद के वर्शन में | डिजिटल ऐसेट लिंक सेट अप होने पर, मंज़ूरी वाली सूची में शामिल, स्वीकार नहीं किया गया |
टेबल 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 उन्हें डिफ़ॉल्ट रूप से फ़िल्टर करता है. इन्हें सिर्फ़ एक ही ऑरिजिन के क्लाइंट और सर्वर पर अटैच करने की अनुमति है. इनकी पुष्टि डिजिटल ऐसेट लिंक से की जाती है.