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

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

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

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

पहली टेबल.: अनुमति वाली सूची में शामिल नहीं किए गए सीओआरएस हेडर को फ़िल्टर करना.

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

बैकग्राउंड

अनुमति वाली सूची में शामिल किए गए वर्सेस अनुमति वाली सूची में शामिल नहीं किए गए सीओआरएस रिक्वेस्ट हेडर

क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) की मदद से, एक ऑरिजिन का वेब ऐप्लिकेशन किसी दूसरे ऑरिजिन के रिसॉर्स का अनुरोध कर सकता है. 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"` का इस्तेमाल करें. इससे पता चलता है कि लिंक की पुष्टि होने के बाद, दोनों ऐप्लिकेशन एक ही ऑरिजिन से जुड़े हैं.

Extra Headers की मदद से, कस्टम टैब इंटेंट बनाना

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

implementation 'androidx.browser:browser:1.2.0'

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

CustomTabsIntent constructExtraHeadersIntent(CustomTabsSession session) {
    CustomTabsIntent intent = new CustomTabsIntent.Builder(session).build();

    // Example non-cors-approvelisted headers.
    Bundle headers = new Bundle();
    headers.putString("bearer-token", "Some token");
    headers.putString("redirect-url", "Some redirect url");
    intent.intent.putExtra(Browser.EXTRA_HEADERS, headers);
    return intent;
}

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

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

// Set up a connection that warms up and validates a session.
CustomTabsServiceConnection connection = new CustomTabsServiceConnection() {
    @Override
    public void onCustomTabsServiceConnected(@NonNull ComponentName name, 
        @NonNull CustomTabsClient client) {
        // Create session after service connected.
        mSession = client.newSession(callback);
        client.warmup(0);
        // Validate the session as the same origin to allow cross origin headers.
        mSession.validateRelationship(CustomTabsService.RELATION_USE_AS_ORIGIN, 
            Uri.parse(url), null);
    }
    @Override
    public void onServiceDisconnected(ComponentName componentName) { }
};

पुष्टि के बाद इंटेंट लॉन्च करने वाला कॉलबैक सेट अप करना

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

// Set up a callback that launches the intent after session validated.
CustomTabsCallback callback = new CustomTabsCallback() {
    @Override
    public void onRelationshipValidationResult(int relation, @NonNull Uri requestedOrigin, 
        boolean result, @Nullable Bundle extras) {
        // Launch custom tabs intent after session was validated as the same origin.
        CustomTabsIntent intent = constructExtraHeadersIntent(mSession);
        intent.launchUrl(MainActivity.this, Uri.parse(url));
    }
};

कस्टम टैब सेवा कनेक्शन को बाइंड करना

सेवा को बाइंड करने से, सेवा लॉन्च हो जाती है. साथ ही, कनेक्शन के 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 repository देखें.

खास जानकारी

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