प्राइवेट स्टेट टोकन डेवलपर के लिए गाइड

पहले, तीसरे पक्ष की कुकी का इस्तेमाल, उपयोगकर्ता की स्थिति से जुड़ी जानकारी को सेव करने और उसे शेयर करने के लिए किया जाता था. जैसे, साइन इन करने की स्थिति, इस्तेमाल किए जा रहे डिवाइस की जानकारी या यह जानकारी कि उपयोगकर्ता जाना-पहचाना और भरोसेमंद है या नहीं. उदाहरण के लिए, उपयोगकर्ता ने एसएसओ (SSO) से लॉग इन किया है या नहीं, उपयोगकर्ता के पास काम करने वाला कोई डिवाइस है या नहीं या उपयोगकर्ता जाना-पहचाना और भरोसेमंद है या नहीं. तीसरे पक्ष की कुकी के इस्तेमाल पर रोक लगाने के बाद, इनमें से कई इस्तेमाल के उदाहरणों को दूसरे तरीकों से पूरा करना होगा.

निजी स्टेट टोकन की मदद से, वेब पर जानकारी शेयर की जा सकती है. हालांकि, शेयर किए जाने वाले डेटा की मात्रा को कंट्रोल करके, निजता को बनाए रखा जा सकता है.

प्राइवेट स्टेट टोकन (पहले इन्हें ट्रस्ट टोकन कहा जाता था) की मदद से, उपयोगकर्ता के भरोसेमंद होने की जानकारी को एक कॉन्टेक्स्ट से दूसरे पर दिखाया जा सकता है. इससे, साइटों को पैसिव ट्रैकिंग के बिना, धोखाधड़ी से निपटने और इंसान और बॉट में अंतर करने में मदद मिलती है.

इस दस्तावेज़ में, प्राइवेट स्टेट टोकन (पीएसटी) लागू करने के बारे में तकनीकी जानकारी दी गई है. ज़्यादा जानकारी के लिए, पीएसटी की खास जानकारी देखें.

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

प्राइवेट स्टेट टोकन कैसे काम करते हैं?

पीएसटी में, जारी करने वाले और रिडीम करने वाले के बीच का संबंध समझना ज़रूरी है. जारी करने वाली और रिडीम करने वाली कंपनी एक ही हो सकती है.

• इश्यूअर - इन इकाइयों के पास किसी उपयोगकर्ता के बारे में कुछ जानकारी होती है. उदाहरण के लिए, वह उपयोगकर्ता बॉट है या नहीं. साथ ही, वे उस जानकारी को उपयोगकर्ता के डिवाइस पर सेव किए गए टोकन में जोड़ती हैं. ज़्यादा जानकारी के लिए, अगले सेक्शन देखें.
• टोकन रिडीम करने वाले - हो सकता है कि इन इकाइयों के पास किसी उपयोगकर्ता के बारे में कोई सिग्नल न हो, लेकिन उन्हें उसके बारे में कुछ जानकारी चाहिए. उदाहरण के लिए, वह उपयोगकर्ता बॉट है या नहीं. साथ ही, उस उपयोगकर्ता की भरोसेमंदता जानने के लिए, जारी करने वाले से टोकन रिडीम करने के लिए कहें.

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

क्या प्राइवेट स्टेट टोकन मेरे काम के हैं?

जिन कंपनियों को भरोसे के आधार पर फ़ैसले लेने हैं और उन्हें यह जानकारी सभी संदर्भों में उपलब्ध करनी है उन्हें पीएसटी से फ़ायदा मिल सकता है. पीएसटी के संभावित इस्तेमाल के उदाहरणों के बारे में ज़्यादा जानने के लिए, पीएसटी के इस्तेमाल के उदाहरणों के बारे में हमारा दस्तावेज़ देखें.

टोकन जारी करना और रिडीम करना

पीएसटी को लागू करने की प्रोसेस तीन चरणों में पूरी होती है:

1. टोकन जारी करना
2. टोकन रिडीम करना
3. रिडेंप्शन रिकॉर्ड को फ़ॉरवर्ड करना

पहले चरण में, ब्राउज़र को टोकन जारी किए जाते हैं. आम तौर पर, ऐसा किसी तरह की पुष्टि करने के बाद किया जाता है. दूसरे चरण में, कोई दूसरी इकाई उस टोकन को रिडीम करने का अनुरोध करेगी जिसे उस टोकन की वैल्यू पढ़ने के लिए जारी किया गया था. आखिरी चरण में, रिडीम करने वाले व्यक्ति को रिडीम रिकॉर्ड (आरआर) मिलता है. इसमें, टोकन में मौजूद वैल्यू होती है. रिडीम करने वाली पार्टी, उस रिकॉर्ड का इस्तेमाल कई कामों के लिए, उस उपयोगकर्ता के पुष्टि के तौर पर कर सकती है.

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

टोकन की रणनीति तय करना

टोकन की रणनीति तय करने के लिए, आपको पीएसटी के मुख्य कॉन्सेप्ट (टोकन और रिडेंप्शन रिकॉर्ड), वैरिएबल, व्यवहार, और सीमाओं को समझना होगा. इससे आपको अपने इस्तेमाल के उदाहरण के लिए, उनके संभावित इस्तेमाल के बारे में सोचने में मदद मिलेगी.

टोकन और रिडीम करने के रिकॉर्ड: इनके बीच क्या संबंध है?

हर डिवाइस में, हर टॉप-लेवल वेबसाइट और जारीकर्ता के लिए ज़्यादा से ज़्यादा 500 टोकन स्टोर किए जा सकते हैं. साथ ही, हर टोकन में मेटाडेटा होता है, जिससे पता चलता है कि जारी करने वाले ने इसे जारी करने के लिए किस पासकोड का इस्तेमाल किया है. इस जानकारी का इस्तेमाल, टोकन रिडीम करने की प्रोसेस के दौरान, टोकन रिडीम करने या न करने का फ़ैसला लेने के लिए किया जा सकता है. पीएसटी डेटा, ब्राउज़र में उपयोगकर्ता के डिवाइस पर सेव किया जाता है. इसे सिर्फ़ पीएसटी एपीआई ऐक्सेस कर सकता है.

टोकन रिडीम करने पर, रिडेंप्शन रिकॉर्ड (आरआर) डिवाइस पर सेव हो जाता है. यह स्टोरेज, आने वाले समय में रिडीम करने के लिए कैश मेमोरी के तौर पर काम करता है. हर डिवाइस, पेज, और जारी करने वाले के लिए, हर 48 घंटे में दो टोकन रिडीम किए जा सकते हैं. नए रिडेंप्शन कॉल, जहां भी हो सके वहां जारी करने वाले को अनुरोध करने के बजाय, कैश मेमोरी में सेव किए गए आरआर का इस्तेमाल करेंगे.

1. नए टोकन जारी किए जाते हैं. हर क्रेडिट कार्ड जारी करने वाली कंपनी, साइट, और डिवाइस के लिए ज़्यादा से ज़्यादा 500 टोकन जारी किए जा सकते हैं.
2. सभी टोकन, डिवाइस के टोकन स्टोर में सेव किए जाते हैं. यह कुकी स्टोर की तरह ही होता है.
3. अगर कोई चालू आरआर नहीं मिलता है, तो जारी करने के बाद नए आरआर जनरेट किए जा सकते हैं (हर 48 घंटे में ज़्यादा से ज़्यादा दो).
4. आरआर को समयसीमा खत्म होने तक ऐक्टिव माना जाता है. साथ ही, उनका इस्तेमाल लोकल कैश मेमोरी के तौर पर किया जाएगा.
5. नए रिडेंप्शन कॉल, लोकल कैश मेमोरी में सेव हो जाएंगे. कोई नया आरआर जनरेट नहीं होगा.

इस्तेमाल के उदाहरण के बारे में बताने के बाद, आपको आरआर के लाइफ़स्पैन के बारे में ध्यान से बताना होगा. इससे यह तय होगा कि आपके उदाहरण में, आरआर का इस्तेमाल कितनी बार किया जा सकता है.

अपनी रणनीति तय करने से पहले, पक्का करें कि आपने इन अहम व्यवहारों और वैरिएबल को समझ लिया हो:

वैरिएबल / व्यवहार	ब्यौरा	संभावित इस्तेमाल
टोकन की मेटाडेटा कुंजी	हर टोकन को सिर्फ़ एक क्रिप्टोग्राफ़िक कुंजी का इस्तेमाल करके जारी किया जा सकता है. साथ ही, पीएसटी में हर जारीकर्ता के लिए छह कुंजियों की सीमा होती है.	इस वैरिएबल का इस्तेमाल करने का एक संभावित तरीका यह है कि एन्क्रिप्शन कुंजियों के आधार पर, अपने टोकन के लिए भरोसे की सीमा तय की जाए. उदाहरण के लिए, कुंजी 1 = ज़्यादा भरोसा, जबकि कुंजी 6 = कोई भरोसा नहीं.
टोकन की समयसीमा खत्म होने की तारीख	टोकन के खत्म होने की तारीख और पासकोड के खत्म होने की तारीख एक ही होती है.	पासकोड को कम से कम हर 60 दिन में बदला जा सकता है. साथ ही, अमान्य पासकोड से जारी किए गए सभी टोकन भी अमान्य माने जाते हैं.
टोकन रिडीम करने की दर की सीमा	हर डिवाइस और जारी करने वाले के लिए, हर 48 घंटे में ज़्यादा से ज़्यादा दो टोकन रिडीम किए जा सकते हैं.	यह इस बात पर निर्भर करता है कि हर 48 घंटे में, आपके इस्तेमाल के उदाहरण के हिसाब से, कितने रिडीमेशन की ज़रूरत है.
हर टॉप लेवल ऑरिजिन के लिए, जारी करने वालों की ज़्यादा से ज़्यादा संख्या	फ़िलहाल, हर टॉप लेवल ऑरिजिन के लिए, ज़्यादा से ज़्यादा दो जारीकर्ता हो सकते हैं.	हर पेज के जारीकर्ताओं की जानकारी ध्यान से दें.
किसी डिवाइस पर, हर जारीकर्ता के टोकन	फ़िलहाल, किसी डिवाइस पर जारीकर्ता के हिसाब से ज़्यादा से ज़्यादा 500 टोकन हो सकते हैं.	पक्का करें कि हर जारीकर्ता के लिए, टोकन की संख्या 500 से कम हो. टोकन जारी करते समय, अपने वेब पेज पर गड़बड़ियों को ठीक करना न भूलें.
डेटा सुरक्षित करने वाली कुंजी का नया वर्शन बनाना	पीएसटी जारी करने वाले हर व्यक्ति या कंपनी को एक एंडपॉइंट उपलब्ध कराना होगा. इसमें, ऐसे ज़रूरी दायित्वों की जानकारी होनी चाहिए जिन्हें हर 60 दिन में बदला जा सकता है. इससे ज़्यादा बार बदलाव करने पर, उसे अनदेखा कर दिया जाएगा.	अगर आपकी कुंजियों की समयसीमा 60 दिनों से कम है, तो उस तारीख से पहले अपनी कुंजियों से जुड़ी जवाबदेही को अपडेट करना ज़रूरी है. ऐसा करने से, आपके कारोबार पर कोई असर नहीं पड़ेगा. ज़्यादा जानकारी के लिए, जानकारी देखें.
रिडीम करने के रिकॉर्ड की समयसीमा	खत्म होने की तारीख तय करने के लिए, आरआर के लाइफ़स्पैन को तय किया जा सकता है. आरआर को कैश मेमोरी में सेव किया जाता है, ताकि जारी करने वाले को रिडीम करने के लिए बार-बार कॉल न करना पड़े. इसलिए, यह पक्का करना ज़रूरी है कि रिडीम करने के लिए नए सिग्नल उपलब्ध हों.	हर 48 घंटे में दो टोकन रिडीम करने की सीमा होती है. इसलिए, कम से कम इस समयावधि के दौरान रिडीम करने के कॉल को सफलतापूर्वक लागू करने के लिए, अपने आरआर के लाइफ़स्पैन को तय करना ज़रूरी है. इसके हिसाब से आरआर का लाइफ़स्पैन सेट किया जाना चाहिए. हमारा सुझाव है कि इस लाइफ़स्पैन को हफ़्तों के हिसाब से सेट करें.

उदाहरण के तौर पर दी गई स्थितियां

स्थिति #1: आरआर का लाइफ़स्पैन 24 घंटे से कम (t=t) है और 48 घंटे की विंडो के दौरान रिडेंप्शन कई बार किया जाता है.

इस स्थिति में, उपयोगकर्ता को 28 घंटे के लिए नए टोकन रिडीम करने की अनुमति नहीं होगी. साथ ही, सभी आरआर की समयसीमा खत्म हो जाएगी.

दूसरी स्थिति: आरआर की समयसीमा 24 घंटे है और 48 घंटे की विंडो के दौरान कई बार रिडीम किया जाता है.

इस स्थिति में, आरआर की समयसीमा 24 घंटे होती है. इसलिए, 48 घंटों के दौरान बिना किसी पाबंदी के रिडीम किया जा सकता है.

तीसरा उदाहरण: आरआर की समयसीमा 48 घंटे है और 48 घंटे की विंडो के दौरान कई बार रिडीम किया जाता है.

इस स्थिति में, आरआर की समयसीमा 48 घंटे होती है. इसलिए, इन 48 घंटों के दौरान बिना किसी पाबंदी के रिडीम किया जा सकता है.

डेमो चलाना

हमारा सुझाव है कि पीएसटी को अपनाने से पहले, डेमो सेट अप करें. पीएसटी डेमो आज़माने के लिए, आपको Chrome को फ़्लैग के साथ चलाना होगा, ताकि डेमो जारी करने वाले के मुख्य दायित्वों को चालू किया जा सके. इसके लिए, डेमो पेज पर दिए गए निर्देशों का पालन करें.

इस डेमो को चलाने पर, आपका ब्राउज़र टोकन देने और इस्तेमाल करने के लिए, डेमो जारी करने वाले और रिडीम करने वाले सर्वर का इस्तेमाल करता है.

इन तकनीकी बातों पर ध्यान दें

डेमो सबसे अच्छी तरह से तब चलेगा, जब आपने यह तरीका अपनाया हो:

• फ़्लैग के साथ Chrome चलाने से पहले, पक्का करें कि आपने Chrome के सभी इंस्टेंस बंद कर दिए हों.
• अगर आपने Chrome को Windows मशीन पर इंस्टॉल किया है, तो Chrome की एक्ज़ीक्यूटेबल बाइनरी में पैरामीटर पास करने का तरीका जानने के लिए, यह गाइड पढ़ें.
• डेमो ऐप्लिकेशन का इस्तेमाल करते समय, ऐप्लिकेशन > स्टोरेज > निजी स्टेट टोकंस में जाकर Chrome DevTools खोलें. इससे, आपको डेमो जारी करने वाले व्यक्ति या इकाई से जारी किए गए/रिडीम किए गए टोकन दिखेंगे.

अपनाने के लिए सेट अप करना

सेवा देने वाली इकाई बनना

पीएसटी में, जारी करने वाले बैंकों की अहम भूमिका होती है. ये टोकन को वैल्यू असाइन करते हैं, ताकि यह तय किया जा सके कि कोई उपयोगकर्ता बॉट है या नहीं. अगर आपको जारी करने वाले के तौर पर पीएसटी का इस्तेमाल शुरू करना है, तो आपको जारी करने वाले के तौर पर रजिस्टर करने की प्रोसेस पूरी करके रजिस्टर करना होगा.

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

जारी करने वाले सर्वर

पीएसटी के लिए, जारी करने वाले और रिडीम करने वाले लोग अहम भूमिका निभाते हैं. साथ ही, सर्वर और टोकन, पीएसटी के लिए अहम टूल हैं. हमने टोकन और GitHub दस्तावेज़ में पहले ही कुछ जानकारी दी है. हालांकि, हम पीएसटी सर्वर के बारे में ज़्यादा जानकारी देना चाहते हैं. पीएसटी जारी करने वाली कंपनी के तौर पर सेट अप करने के लिए, आपको सबसे पहले जारी करने वाला सर्वर सेट अप करना होगा.

अपना एनवायरमेंट डिप्लॉय करना: कार्ड जारी करने वाले बैंक के सर्वर

टोकन जारी करने वाले सर्वर को लागू करने के लिए, आपको एचटीटीपी एंडपॉइंट दिखाने वाला अपना सर्वर साइड ऐप्लिकेशन बनाना होगा.

जारी करने वाले के कॉम्पोनेंट में दो मुख्य मॉड्यूल होते हैं: (1) जारी करने वाला सर्वर और (2) टोकन जारी करने वाला.

हमारा सुझाव है कि आप अपने जारीकर्ता सर्वर को ज़्यादा सुरक्षित बनाएं. ऐसा वेब पर काम करने वाले सभी ऐप्लिकेशन के लिए ज़रूरी है.

1. जारी करने वाला सर्वर: लागू करने के हमारे उदाहरण में, हमारा जारी करने वाला सर्वर एक Node.js सर्वर है. यह जारी करने वाले एचटीटीपी एंडपॉइंट को होस्ट करने के लिए, Express फ़्रेमवर्क का इस्तेमाल करता है. GitHub पर सैंपल कोड देखा जा सकता है.

2. टोकन जारी करने वाला: जारी करने वाले क्रिप्टोग्राफ़िक कॉम्पोनेंट के लिए, किसी खास भाषा की ज़रूरत नहीं होती. हालांकि, इस कॉम्पोनेंट की परफ़ॉर्मेंस से जुड़ी ज़रूरी शर्तों की वजह से, हम उदाहरण के तौर पर C प्रोग्रामिंग भाषा का इस्तेमाल कर रहे हैं. यह भाषा, टोकन मैनेज करने के लिए BoringSSL लाइब्रेरी का इस्तेमाल करती है. इश्यूअर कोड का उदाहरण और इंस्टॉलेशन के बारे में ज़्यादा जानकारी, GitHub पर देखी जा सकती है

3. कुंजियां: टोकन जारी करने वाला कॉम्पोनेंट, टोकन एन्क्रिप्ट (सुरक्षित) करने के लिए कस्टम ईसी कुंजियों का इस्तेमाल करता है. इन कुंजियों को सुरक्षित स्टोरेज में सेव और सुरक्षित रखना ज़रूरी है.

सर्टिफ़िकेट जारी करने वाले सर्वर के लिए तकनीकी ज़रूरतें

प्रोटोकॉल के मुताबिक, आपको अपने जारीकर्ता सर्वर में कम से कम दो एचटीटीपी एंडपॉइंट लागू करने होंगे:

• पासकोड का एन्क्रिप्शन (उदाहरण के लिए, /.well-known/private-state-token/key-commitment): इस एंडपॉइंट पर, एन्क्रिप्शन की सार्वजनिक कुंजी की जानकारी ब्राउज़र के लिए उपलब्ध होगी. इससे यह पुष्टि की जा सकेगी कि आपका सर्वर मान्य है.
  • कोड का उदाहरण
• टोकन जारी करने वाला एंडपॉइंट (उदाहरण के लिए, /.well-known/private-state-token/issuance): टोकन जारी करने वाला एंडपॉइंट, जहां टोकन के सभी अनुरोधों को मैनेज किया जाएगा. यह एंडपॉइंट, टोकन जारी करने वाले कॉम्पोनेंट के लिए इंटिग्रेशन पॉइंट होगा.
  • कोड का उदाहरण

जैसा कि पहले बताया गया है, इस सर्वर पर ज़्यादा ट्रैफ़िक आने की संभावना है. इसलिए, हमारा सुझाव है कि आप इसे स्केलेबल इन्फ़्रास्ट्रक्चर (उदाहरण के लिए, क्लाउड एनवायरमेंट) का इस्तेमाल करके डिप्लॉय करें. इससे, मांग के हिसाब से अपने बैकएंड में बदलाव किया जा सकेगा.

जारी करने वाले बैंक के सर्वर को कॉल भेजना

नए टोकन जारी करने के लिए, अपने जारी करने वाले स्टैक में वेबसाइट फ़ेच कॉल लागू करें.

 // issuer request
    await fetch("/.well-known/private-state-token/issuance", {
      method: "POST",
      privateToken: {
        version: 1,
        operation: "token-request"
      }
    });

कोड का उदाहरण देखें.

ध्यान दें: स्थानीय तौर पर जारी करने वाले सर्वर को चलाते समय, पक्का करें कि आपके स्थानीय एंडपॉइंट के लिए एन्क्रिप्ट किया गया चैनल (TLS) हो: स्थानीय डेवलपमेंट के लिए एचटीटीपीएस का इस्तेमाल कैसे करें देखें. Sec- हेडर के बारे में ज़्यादा जानकारी देखें.

रिडीमर सर्वर

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

आपके पास एक ही सर्वर (या सर्वर के ग्रुप) में, जारी करने वाले और रिडीम करने वाले को चलाने का विकल्प होता है.

पीएसटी डेमो कॉम्पोनेंट: ये रिडीमर सर्वर के मुख्य कॉम्पोनेंट हैं. रिडीमर सर्वर (Node.js ऐप्लिकेशन) और टोकन रिडीमर (रिडीम करने की प्रोसेस में हस्ताक्षर और टोकन की पुष्टि करने के लिए ज़िम्मेदार क्रिप्टोग्राफ़िक कॉम्पोनेंट).

रिडीमर सर्वर के लिए तकनीकी ज़रूरतें

प्रोटोकॉल के मुताबिक, आपको अपने रिडीमर सर्वर के लिए कम से कम दो एचटीटीपी एंडपॉइंट लागू करने होंगे:

• /.well-known/private-state-token/redemption: वह एंडपॉइंट जहां सभी टोकन रिडीम किए जाएंगे. इस एंडपॉइंट पर, टोकन रिडीमर कॉम्पोनेंट को इंटिग्रेट किया जाएगा
  • कोड का उदाहरण

रिडीमर सर्वर को कॉल भेजना

टोकन रिडीम करने के लिए, आपको अपने रिडीमर स्टैक में वेबसाइट फ़ेच कॉल लागू करना होगा, ताकि पहले जारी किए गए टोकन रिडीम किए जा सकें.

    // redemption request
    await fetch("/.well-known/private-state-token/redemption", {
      method: "POST",
      privateToken: {
        version: 1,
        operation: "token-redemption",
        refreshPolicy: "none"
      }
    });

कोड का सैंपल देखें.

टोकन रिडीम करने के बाद, फ़ेच करने का एक और कॉल करके रिडीम रिकॉर्ड (आरआर) भेजा जा सकता है:

    // attach redemption records from the issuers to the request
    await fetch("<DESTINATION_RESOURCE>", {
      method: "POST",
      privateToken: {
        version: 1,
        operation: "send-redemption-record",
        issuers: [<ISSUER_DOMAIN>]
      }
    });

कोड का सैंपल देखें.

लागू करने की प्रोसेस को डिप्लॉय करना

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

असल दुनिया में डिप्लॉयमेंट

हमारा सुझाव है कि आप ऐसी टारगेट वेबसाइटें चुनें जो आपके इस्तेमाल के उदाहरण का हिस्सा हों:

• हर महीने कम विज़िट (~ 10 लाख विज़िट/महीने से कम): आपको पहले कम ऑडियंस के लिए एपीआई को डिप्लॉय करना चाहिए
• आपके पास इसका मालिकाना हक है और इसे कंट्रोल करने का अधिकार है: ज़रूरत पड़ने पर, आपके पास इसे तुरंत बंद करने का विकल्प है. इसके लिए, आपको किसी भी तरह की अनुमति लेने की ज़रूरत नहीं है
• एक से ज़्यादा जारीकर्ता नहीं: जांच को आसान बनाने के लिए, टोकन की संख्या को सीमित करना.
• एक से ज़्यादा लोग रिडीम न कर पाएं: समस्याओं के मामले में, आपको समस्या हल करने का तरीका आसान बनाना होगा.

अनुमतियों की नीति

सही तरीके से काम करने के लिए, पीएसटी एपीआई को टॉप-लेवल पेज और एपीआई का इस्तेमाल करने वाले सभी सब-रिसॉर्स के लिए उपलब्ध होना चाहिए.

टोकन-अनुरोध ऑपरेशन को private-state-token-issuance डायरेक्टिव से कंट्रोल किया जाता है. token-redemption और send-redemption-record ऑपरेशन को private-state-token-redemption डायरेक्टिव से कंट्रोल किया जाता है. Chrome 132 और उसके बाद के वर्शन में, इन निर्देशों के लिए अनुमति वाली सूची डिफ़ॉल्ट रूप से * (सभी ऑरिजिन) पर सेट होती है. इसका मतलब है कि यह सुविधा, टॉप-लेवल पेज, एक ही ऑरिजिन वाले iframe, और क्रॉस-ऑरिजिन iframe के लिए उपलब्ध है. इसके लिए, साफ़ तौर पर अनुमति देने की ज़रूरत नहीं है.

अपनी साइट के कुछ पेजों के लिए, पीएसटी टोकन जारी करने या रिडीम करने की सुविधा से ऑप्ट आउट किया जा सकता है. इसके लिए, हर पेज के लिए Permissions-Policy हेडर में private-state-token-issuance=() और private-state-token-redemption=() शामिल करें.

Permissions-Policy हेडर का इस्तेमाल करके, तीसरे पक्ष के लिए पीएसटी का ऐक्सेस कंट्रोल भी किया जा सकता है. हेडर ऑरिजिन की सूची के पैरामीटर के तौर पर, self और उन सभी ऑरिजिन का इस्तेमाल करें जिन्हें आपको एपीआई को ऐक्सेस करने की अनुमति देनी है. उदाहरण के लिए, अपने ऑरिजिन और https://example.com को छोड़कर, सभी ब्राउज़िंग कॉन्टेक्स्ट में पीएसटी के इस्तेमाल को पूरी तरह से बंद करने के लिए, नीचे दिए गए एचटीटीपी रिस्पॉन्स हेडर सेट करें:

Permissions-Policy:private-state-token-issuance=(self "https://example.com"),private-state-token-redemption=(self "https://example.com")

सभी क्रॉस-ऑरिजिन संसाधनों के लिए एपीआई को चालू करने के लिए, ऑरिजिन की सूची को * पर सेट करें.

ध्यान दें: डिफ़ॉल्ट नीति * है. इसके बावजूद, इस सुविधा का ऐक्सेस पाने के लिए, iframe एलिमेंट को अपने allow एट्रिब्यूट में private-state-token-issuance और private-state-token-redemption निर्देश शामिल करने होंगे. iframe allow एट्रिब्यूट के बारे में ज़्यादा जानें.

अनुमतियों की नीति की मदद से, Privacy Sandbox की सुविधाओं को कंट्रोल करने का तरीका जानें या अनुमतियों की नीति को बेहतर तरीके से समझें.

समस्या का हल

Chrome DevTools के नेटवर्क और ऐप्लिकेशन टैब से, पीएसटी की जांच की जा सकती है.

नेटवर्क टैब पर:

पीएसटी के लिए DevTools की जांच: किसी खास पेज के टोकन और जारी करने वालों के बारे में पूरी जानकारी पाने के लिए, नेटवर्क > निजी स्टेटस टोकन पर जाएं.

'ऐप्लिकेशन' टैब में:

पीएसटी के लिए DevTools की जांच: किसी खास पेज के टोकन और जारी करने वालों के बारे में पूरी जानकारी पाने के लिए, ऐप्लिकेशन > निजी स्टेटस टोकन पर जाएं.

इस DevTools इंटिग्रेशन के बारे में ज़्यादा पढ़ें.

ध्यान दें: पीएसटी को उपयोगकर्ता स्टोरेज से मिटा सकते हैं. साथ ही, किसी डिवाइस पर भरोसा किया जा सकता है या नहीं, यह तय करने के लिए सिर्फ़ पीएसटी का इस्तेमाल नहीं किया जाना चाहिए. आपको हमेशा, जोखिम से जुड़े फ़ैसले के लिए, पीएसटी का इस्तेमाल एक अतिरिक्त सिग्नल के तौर पर करना चाहिए.

क्लाइंट के लिए सबसे सही तरीके

अगर आपकी वेबसाइट के अहम फ़ंक्शन, टोकन जारी करने वाली कुछ कंपनियों पर निर्भर हैं, तो उन्हें प्राथमिकता दें. किसी भी दूसरी स्क्रिप्ट को लोड करने से पहले, इन पसंदीदा जारीकर्ताओं के लिए hasPrivateToken(issuer) को कॉल करें. कूपन रिडीम न हो पाने की समस्या से बचने के लिए, यह ज़रूरी है.

हर टॉप-लेवल के लिए, hasPrivateToken(issuer) को सिर्फ़ दो बार कॉल किया जा सकता है. साथ ही, तीसरे पक्ष की स्क्रिप्ट भी अपने पसंदीदा जारीकर्ताओं को प्राथमिकता देने के लिए, hasPrivateToken(issuer) को कॉल करने की कोशिश कर सकती हैं. इसलिए, ज़रूरी कार्ड जारी करने वाली कंपनियों को पहले से सुरक्षित कर लें, ताकि यह पक्का किया जा सके कि आपकी साइट उम्मीद के मुताबिक काम करे.

  // Prioritize your critical token issuer.
  document.hasPrivateToken('https://critical-issuer.example')
    .then(hasToken => {
      if (hasToken) {
        // Use the token or perform actions based on its availability.
      } else {
        // Handle the case where the token is not available.
      }
    });

  // Load third-party scripts or secure another token issuer (up to two in total).

सर्वर के लिए सबसे सही तरीके और समस्या हल करना

हमारा सुझाव है कि आपका जारी करने वाला और रिडीम करने वाला सर्वर असरदार तरीके से काम करे, इसके लिए यहां दिए गए सबसे सही तरीके अपनाएं. इससे आपको पीएसटी के लिए, ऐक्सेस, सुरक्षा, लॉगिंग या ट्रैफ़िक से जुड़ी कोई समस्या नहीं होगी.

• आपके एंडपॉइंट को TLS 1.3 या 1.2 का इस्तेमाल करके, जानकारी को सुरक्षित करने का मज़बूत तरीका अपनाना होगा.
• आपका इंफ़्रास्ट्रक्चर, अलग-अलग ट्रैफ़िक वॉल्यूम (इसमें स्पाइक भी शामिल हैं) को मैनेज करने के लिए तैयार होना चाहिए.
• पक्का करें कि आपकी कुंजियां सुरक्षित हों और ऐक्सेस कंट्रोल नीति, कुंजी मैनेजमेंट की रणनीति, और कारोबार को लगातार चलाने के प्लान के मुताबिक हों.
• अपने स्टैक में निगरानी मेट्रिक जोड़ें, ताकि प्रोडक्शन में जाने के बाद, इस्तेमाल, रुकावटों, और परफ़ॉर्मेंस से जुड़ी समस्याओं को समझने के लिए, आपके पास जानकारी हो.

ज़्यादा जानकारी

1. डेवलपर के दस्तावेज़ पढ़ें:
   1. पीएसटी और इसकी सुविधाओं के बारे में जानने के लिए, खास जानकारी पढ़ें.
   2. पीएसटी के बारे में जानकारी देने वाला वीडियो देखें.
   3. पीएसटी का डेमो आज़माएं.
   4. इसके बारे में ज़्यादा जानने के लिए, एपीआई के एक्सप्लेनर को भी पढ़ें.
   5. एपीआई के मौजूदा स्पेसिफ़िकेशन के बारे में ज़्यादा जानें.
2. GitHub के मुद्दों या W3C के कॉल के ज़रिए बातचीत में योगदान दें.
3. किसी भी शब्दावली को बेहतर तरीके से समझने के लिए, Privacy Sandbox की ग्लॉसरी देखें.
4. 'ऑरिजिन ट्रायल' या 'Chrome फ़्लैग' जैसे Chrome के कॉन्सेप्ट के बारे में ज़्यादा जानने के लिए, goo.gle/cc पर उपलब्ध छोटे वीडियो और लेख पढ़ें.