पहले, तीसरे पक्ष की कुकी का इस्तेमाल किसी उपयोगकर्ता की स्थिति, जैसे कि साइन-इन की स्थिति, उसके डिवाइस के बारे में जानकारी या उसे जानने और भरोसेमंद होने की जानकारी को सेव करने और बताने के लिए किया जाता था. उदाहरण के लिए, क्या उपयोगकर्ता ने एसएसओ (SSO) की मदद से लॉग इन किया है या नहीं, उपयोगकर्ता के पास किसी खास तरह का डिवाइस है या नहीं या क्या उपयोगकर्ता जाना-पहचाना और भरोसेमंद है. तीसरे पक्ष की कुकी की सुविधा बंद होने वाली है. इसलिए, इस्तेमाल के इनमें से ज़्यादातर उदाहरणों को दूसरे तरीकों से काम करना होगा.
प्राइवेट स्टेट टोकन की मदद से वेब पर जानकारी शेयर की जा सकती है. हालांकि, शेयर किए जा सकने वाले डेटा की मात्रा को कंट्रोल करने के ज़रिए, निजता बनाए रखते हुए इसे शेयर किया जा सकता है.
प्राइवेट स्टेट टोकन (जिसे पहले ट्रस्ट टोकन के नाम से जाना जाता था) का इस्तेमाल करके, उपयोगकर्ता का भरोसा एक से दूसरे संदर्भ पर शेयर किया जा सकता है. साथ ही, धोखाधड़ी से लड़ने और बॉट के बीच अंतर करने में भी साइटों की मदद की जा सकती है.
इस दस्तावेज़ में प्राइवेट स्टेट टोकन (पीएसटी) को लागू करने के लिए तकनीकी जानकारी दी गई है. ज़्यादा विस्तार से जानकारी पाने के लिए, पीएसटी की खास जानकारी देखें.
प्राइवेट स्टेट टोकन कैसे काम करते हैं?
पीएसटी में समझने के लिए, जारी करने वालों और रिडीम करने वालों के बीच एक अहम संबंध है. जारी करने वाले और रिडीम करने वाले, एक ही कंपनी के हो सकते हैं.
- जारी करने वाले - इन इकाइयों के पास उपयोगकर्ता के बारे में कुछ जानकारी होती है (उदाहरण के लिए, चाहे वह उपयोगकर्ता बॉट है या नहीं) और उस सिग्नल को उपयोगकर्ता के डिवाइस पर सेव होने वाले टोकन में एम्बेड करती है (अगले सेक्शन में ज़्यादा जानकारी).
- रिडीम करने वाले - इन इकाइयों को उपयोगकर्ता के बारे में सिग्नल नहीं मिलेंगे, लेकिन इन इकाइयों को उनके बारे में कुछ जानने की ज़रूरत होती है (उदाहरण के लिए, उपयोगकर्ता बॉट है या नहीं). साथ ही, उपयोगकर्ता के भरोसे को समझने के लिए, उसे जारी करने वाले से टोकन रिडीम करने के लिए कहें.
हर पीएसटी इंटरैक्शन के लिए ज़रूरी है कि जारी करने वाले और रिडीम करने वाले, वेब पर सिग्नल शेयर करने के लिए एक साथ काम करें. ये सिग्नल मामूली वैल्यू होती हैं, जिनसे किसी व्यक्ति की पहचान करने के लिए, इतना ज़्यादा जानकारी नहीं मिलती.
क्या प्राइवेट स्टेट टोकन मेरे लिए सही हैं?
ऐसी कंपनियों को पीएसटी से फ़ायदा हो सकता है जो भरोसे के आधार पर फ़ैसले लेते हैं और चाहते हैं कि यह जानकारी सभी के लिए उपलब्ध हो. पीएसटी के इस्तेमाल के संभावित उदाहरणों के बारे में ज़्यादा जानने के लिए, पीएसटी के इस्तेमाल के उदाहरणों से जुड़ा हमारा दस्तावेज़ देखें.
टोकन जारी करें और रिडीम करें
पीएसटी को लागू करने की प्रोसेस तीन चरणों में होती है:
- टोकन जारी करना
- टोकन रिडीम करना
- रिडेंप्शन रिकॉर्ड फ़ॉरवर्ड करने की सुविधा
पहले चरण में, ब्राउज़र को टोकन जारी किए जाते हैं (आम तौर पर किसी तरह की पुष्टि के बाद). दूसरे चरण में, दूसरी इकाई उस टोकन को रिडीम करने का अनुरोध करेगी जो उस टोकन की वैल्यू पढ़ने के लिए जारी किया गया था. आखिरी चरण में, रिडीम करने वाले पक्ष को टोकन में मौजूद वैल्यू के साथ रिडेंप्शन रिकॉर्ड (आरआर) मिलता है. इसके बाद, वह पक्ष रिडीम करने वाला पक्ष, अलग-अलग कामों के लिए उस रिकॉर्ड का इस्तेमाल उस उपयोगकर्ता के पुष्टि के तौर पर कर सकता है.
टोकन की रणनीति तय करें
टोकन की रणनीति तय करने के लिए, आपको पीएसटी के मुख्य सिद्धांतों (टोकन और रिडीम करने के रिकॉर्ड), वैरिएबल, व्यवहार, और सीमाओं को समझना होगा. इससे आपको इस्तेमाल के उदाहरण में इनके संभावित इस्तेमाल के बारे में जानने में मदद मिलेगी.
टोकन और रिडीम करने के रिकॉर्ड: इनके बीच क्या संबंध है?
हर टॉप लेवल वेबसाइट और उसे जारी करने वाले के लिए, हर डिवाइस ज़्यादा से ज़्यादा 500 टोकन स्टोर कर सकता है. साथ ही, हर टोकन में मेटाडेटा होता है, जो यह बताता है कि जारी करने वाले ने किस कुंजी का इस्तेमाल करके इसे जारी किया है. इस जानकारी का इस्तेमाल, यह तय करने के लिए किया जा सकता है कि रिडीम करने की प्रोसेस के दौरान, किसी टोकन को रिडीम करना है या नहीं. PST डेटा को उपयोगकर्ता के डिवाइस पर ब्राउज़र में अंदरूनी तौर पर सेव किया जाता है और इसे सिर्फ़ PST एपीआई से ऐक्सेस किया जा सकता है.
जब किसी टोकन को रिडीम किया जाता है, तो रिडेंप्शन रिकॉर्ड (आरआर) डिवाइस में सेव हो जाता है. इस स्टोरेज का इस्तेमाल, आने वाले समय में रिडीम किए जाने के लिए किया जा सकता है. किसी डिवाइस, पेज, और उसे जारी करने वाले के लिए, हर 48 घंटे में दो टोकन को रिडीम करने की सीमा तय है. नए रिडेंप्शन कॉल, जारी करने वाले से अनुरोध करने के बजाय, जहां संभव हो वहां कैश मेमोरी में सेव किए गए आरआर का इस्तेमाल करेंगे.
- नए टोकन जारी किए जाते हैं (हर जारी करने वाले, साइट, और डिवाइस के लिए ज़्यादा से ज़्यादा 500 टोकन).
- सभी टोकन, कुकी स्टोर की तरह ही, डिवाइस के टोकन स्टोर में सेव किए जाते हैं.
- अगर कोई चालू आरआर नहीं मिलता है, तो जारी करने के बाद नए आरआर जनरेट किए जा सकते हैं. हर 48 घंटे में ज़्यादा से ज़्यादा दो आरआर जनरेट किए जा सकते हैं.
- आरआर को समयसीमा खत्म होने तक ऐक्टिव माना जाता है. उनका इस्तेमाल लोकल कैश मेमोरी के तौर पर किया जाता है.
- नए रिडेंप्शन कॉल, लोकल कैश मेमोरी में सेव होंगे (नए आरआर जनरेट नहीं होंगे).
इस्तेमाल का उदाहरण तय करने के बाद, आपको अपने आरआर की अवधि को सावधानी से तय करना होगा. इससे यह तय होगा कि आपके केस में इनका इस्तेमाल कितनी बार किया जा सकेगा.
अपनी रणनीति तय करने से पहले, पक्का करें कि आपने इन अहम व्यवहार और वैरिएबल को समझ लिया है:
| वैरिएबल / व्यवहार | ब्यौरा | संभावित इस्तेमाल |
|---|---|---|
| टोकन कुंजी का मेटाडेटा | हर टोकन को सिर्फ़ एक क्रिप्टोग्राफ़िक कुंजी का इस्तेमाल करके जारी किया जा सकता है. साथ ही, पीएसटी में हर टोकन जारी करने वाले व्यक्ति के लिए, ज़्यादा से ज़्यादा छह कुंजियों का इस्तेमाल किया जा सकता है. | इस वैरिएबल का इस्तेमाल करने का एक संभावित तरीका यह है कि आप अपनी क्रिप्टोग्राफ़िक कुंजियों के आधार पर अपने टोकन के लिए कितने भरोसेमंद हैं. उदाहरण के लिए, कुंजी 1 = ज़्यादा भरोसा, जबकि कुंजी 6 = कोई भरोसा नहीं. |
| टोकन के खत्म होने की तारीख | टोकन के खत्म होने की तारीख और कुंजी खत्म होने की तारीख एक ही होती है. | कुंजियों को कम से कम हर 60 दिन में बदला जा सकता है. साथ ही, अमान्य कुंजियों से जारी किए गए सभी टोकन भी अमान्य माने जाते हैं. |
| टोकन को रिडीम करने की दर की सीमा | किसी डिवाइस और उसे जारी करने वाले, हर 48 घंटे में दो बार टोकन रिडीम किए जा सकते हैं. | यह हर 48 घंटे में इस्तेमाल किए जाने के हिसाब से, ऑफ़र रिडीम करने की अनुमानित संख्या पर निर्भर करता है. |
| टॉप लेवल ऑरिजिन के लिए, जारी करने वालों की ज़्यादा से ज़्यादा संख्या | फ़िलहाल, हर टॉप लेवल ऑरिजिन के लिए जारी करने वालों की ज़्यादा से ज़्यादा संख्या दो है. | हर पेज को जारी करने वाले के बारे में ध्यान से बताएं. |
| डिवाइस पर, हर जारी करने वाले के हिसाब से टोकन | फ़िलहाल, किसी डिवाइस पर ज़्यादा से ज़्यादा 500 टोकन इस्तेमाल किए जा सकते हैं. | यह पक्का करें कि हर जारी करने वाले के लिए, 500 से कम टोकन हों. पक्का करें कि टोकन जारी करते समय, आपके वेब पेज पर होने वाली गड़बड़ियों को ठीक करना हो. |
| मुख्य प्रतिबद्धताओं का रोटेशन | हर पीएसटी को जारी करने वाले के लिए ज़रूरी है कि वह अहम प्रतिबद्धता वाला एंडपॉइंट उपलब्ध कराए, जिसे हर 60 दिन में बदला जा सकता है. साथ ही, अगर किसी भी समय को इतनी तेज़ी से बदला जा सकता है, तो उसे अनदेखा कर दिया जाएगा. | अगर 60 दिनों से कम समय में आपकी कुंजियों की समयसीमा खत्म होने वाली है, तो रुकावट से बचने के लिए अपने मुख्य वादे अपडेट करना ज़रूरी है. (जानकारी देखें). |
| रिडेंप्शन रिकॉर्ड की समयसीमा | आरआर की अवधि को खत्म होने की तारीख तय करने के लिए तय किया जा सकता है. आरआर को कैश मेमोरी में सेव किया जाता है, ताकि जारी करने वाले को बेवजह नए रिडेंप्शन कॉल न मिलें. इसलिए, यह पक्का करना ज़रूरी है कि आपके पास रिडेंप्शन के नए सिग्नल हों. | रिडेंप्शन रेट की सीमा, हर 48 घंटे में दो टोकन की होती है. इसलिए, यह तय करना ज़रूरी है कि आपका आरआर कितने समय तक इस्तेमाल किया जाए, ताकि कम से कम इस अवधि में रिडेंप्शन कॉल पूरे किए जा सकें. आरआर की समयसीमा उसी हिसाब से सेट की जानी चाहिए. हमारा सुझाव है कि इस अवधि को हफ़्तों के हिसाब से सेट करें. |
उदाहरण के तौर पर दिया गया मामला
स्थिति #1: RR की लाइफ़टाइम वैल्यू 24 घंटे से कम (t=t) होती है और रिडीम करने की प्रोसेस 48-घंटे की विंडो के दौरान कई बार की जाती है.
स्थिति #2: आरआर की लाइफ़ 24 घंटे होती है और 48 घंटे की अवधि के दौरान, ऑफ़र रिडीम करने की प्रोसेस कई बार की जाती है.
स्थिति #3: आरआर की लाइफ़ 48 घंटे होती है और 48 घंटे की अवधि के दौरान, ऑफ़र रिडीम करने की प्रोसेस कई बार की जाती है.
डेमो चलाएं
हमारा सुझाव है कि पीएसटी का इस्तेमाल करने से पहले, डेमो के साथ इसे सेट अप कर लें. पीएसटी डेमो को आज़माने के लिए, आपको Chrome को फ़्लैग के साथ चलाना होगा, ताकि डेमो जारी करने वाले व्यक्ति की अहम प्रतिबद्धताएं चालू रखी जा सकें. डेमो पेज पर दिए गए निर्देशों का पालन करें.
इस डेमो को चलाने पर आपका ब्राउज़र, टोकन देने और उनका इस्तेमाल करने के लिए, डेमो जारी करने वाले और रिडीमर सर्वर का इस्तेमाल कर रहा है.
इन तकनीकी बातों पर ध्यान दें
नीचे दिए गए तरीके लागू करने पर, डेमो सबसे सही तरीके से चलेगा:
- Chrome को फ़्लैग के साथ चलाने से पहले, पक्का करें कि आपने Chrome के सभी इंस्टेंस बंद कर दिए हों.
- अगर Windows मशीन का इस्तेमाल किया जा रहा है, तो Chrome की एक्ज़ीक्यूटेबल बाइनरी में पैरामीटर पास करने के तरीके के बारे में जानने के लिए यह गाइड देखें.
- डेमो ऐप्लिकेशन पर जाकर, डेमो जारी करने वाले/की ओर से जारी/रिडीम किए गए टोकन देखने के लिए, ऐप्लिकेशन > स्टोरेज > प्राइवेट स्टेट टोकन में Chrome DevTools खोलें.
इस्तेमाल के लिए सेट अप करें
क्रेडिट कार्ड जारी करने वाला बैंक या कंपनी बनें
सर्टिफ़िकेट देने वाले लोग या कंपनियां, पीएसटी में अहम भूमिका निभाती हैं. वे टोकन के लिए वैल्यू असाइन करते हैं, ताकि यह पता लगाया जा सके कि उपयोगकर्ता बॉट है या नहीं. अगर आपको पीएसटी को जारी करने वाले के तौर पर इस्तेमाल करना है, तो आपको रजिस्ट्रेशन जारी करने वाले व्यक्ति के लिए रजिस्ट्रेशन की प्रक्रिया पूरी करके, रजिस्ट्रेशन करना होगा.
इसे जारी करने वाले बैंक या कंपनी की वेबसाइट के ऑपरेटर को, "नया पीएसटी जारी करने वाले" टेंप्लेट का इस्तेमाल करके, GitHub डेटा स्टोर करने की जगह पर, नई समस्या को खोलना होगा. समस्या को भरने के लिए, डेटा स्टोर करने की जगह पर दिए गए दिशा-निर्देशों का पालन करें. एंडपॉइंट की पुष्टि हो जाने के बाद, उसे इस डेटा स्टोर करने की जगह के साथ मर्ज कर दिया जाएगा. साथ ही, Chrome का सर्वर-साइड इंफ़्रास्ट्रक्चर, उन कुंजियों को फ़ेच करना शुरू कर देगा.
जारी करने वाले सर्वर
पीएसटी के लिए, जारी करने वाले और रिडीम करने वाले मुख्य उपयोगकर्ता हैं. सर्वर और टोकन, पीएसटी के लिए मुख्य टूल हैं. हम टोकन के बारे में कुछ जानकारी पहले ही दे चुके हैं. साथ ही, GitHub के दस्तावेज़ में, हम पीएसटी सर्वर के बारे में ज़्यादा जानकारी देना चाहते हैं. पीएसटी के जारी करने वाले के तौर पर सेट अप करने के लिए, आपको पहले जारी करने वाला सर्वर सेट अप करना होगा.
अपना एनवायरमेंट डिप्लॉय करें: जारी करने वाले के सर्वर
टोकन जारी करने वाले सर्वर को लागू करने के लिए, आपको खुद का सर्वर साइड ऐप्लिकेशन बनाना होगा, जिसमें एचटीटीपी एंडपॉइंट शामिल हों.
जारी करने वाले कॉम्पोनेंट में दो मुख्य मॉड्यूल होते हैं: (1) जारी करने वाला सर्वर और (2) टोकन जारी करने वाला.
वेब पर इस्तेमाल किए जाने वाले सभी ऐप्लिकेशन की तरह, हम आपके जारी करने वाले सर्वर को सुरक्षा की एक अतिरिक्त स्तर देने का सुझाव देते हैं.
जारी करने वाला सर्वर: लागू करने के हमारे उदाहरण में, हमारा सर्वर एक Node.js सर्वर है, जो जारी करने वाले एचटीटीपी एंडपॉइंट को होस्ट करने के लिए एक्सप्रेस फ़्रेमवर्क का इस्तेमाल करता है. GitHub पर सैंपल कोड देखें.
टोकन जारी करने वाले के क्रिप्टोग्राफ़िक कॉम्पोनेंट को किसी खास भाषा की ज़रूरत नहीं है, लेकिन इस कॉम्पोनेंट की परफ़ॉर्मेंस की शर्तों की वजह से, हम उदाहरण के तौर पर C लागू करने की सुविधा दे रहे हैं, जिसमें टोकन मैनेज करने के लिए Boring SSL लाइब्रेरी का इस्तेमाल किया जाता है. GitHub पर इंस्टॉलेशन जारी करने वाले कोड का उदाहरण और GitHub पर इंस्टॉल करने के बारे में ज़्यादा जानकारी
कुंजियां: टोकन जारी करने वाला कॉम्पोनेंट, टोकन को एन्क्रिप्ट करने के लिए कस्टम EC कुंजियों का इस्तेमाल करता है. इन कुंजियों को सुरक्षित रखना और स्टोरेज में स्टोर करना ज़रूरी है.
जारी करने वाले सर्वर के लिए तकनीकी ज़रूरतें
प्रोटोकॉल के मुताबिक, आपको अपने जारी करने वाले सर्वर में कम से कम दो एचटीटीपी एंडपॉइंट लागू करने होंगे:
- कुंजी की प्रतिबद्धता (उदाहरण के लिए,
/.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"
}
});
रिडीमर सर्वर
आपको अपना सर्वर-साइड ऐप्लिकेशन बनाकर, टोकन रिडेंप्शन सेवा लागू करनी होगी. इससे, जारी करने वाले के टोकन को पढ़ने में मदद मिलेगी. नीचे दिए गए चरणों में, टोकन रिडीम करने का तरीका बताया गया है. साथ ही, उन टोकन से जुड़े रिडेंप्शन रिकॉर्ड को पढ़ने का तरीका भी बताया गया है.
आपके पास, जारी करने वाले और रिडीम करने वाले को एक ही सर्वर (या सर्वर के ग्रुप) में चलाने का विकल्प है.
रिडीमर सर्वर के लिए तकनीकी ज़रूरतें
प्रोटोकॉल के मुताबिक, आपको अपने रिडीमर सर्वर के लिए कम से कम दो एचटीटीपी एंडपॉइंट लागू करने होंगे:
/.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 लाख विज़िट/महीने): आपको सबसे पहले एपीआई को छोटी ऑडियंस के लिए डिप्लॉय करना होगा
- इसका मालिकाना हक आपके पास होता है और इसे मैनेज करने का अधिकार आपके पास होता है. अगर ज़रूरी हो, तो ज़रूरत पड़ने पर मुश्किल अनुमतियों के बिना उसे लागू करने की प्रोसेस को तुरंत बंद किया जा सकता है
- एक से ज़्यादा जारी करने वाले के पास नहीं: टेस्टिंग को आसान बनाने के लिए, टोकन की संख्या सीमित करना.
- दो से ज़्यादा रिडीमर नहीं होने चाहिए: कोई समस्या आने पर, आपको समस्या हल करने की प्रोसेस को आसान बनाना होगा.
समस्या हल करना
Chrome DevTools नेटवर्क और ऐप्लिकेशन टैब से, पीएसटी की जांच की जा सकती है.
नेटवर्क टैब पर:
ऐप्लिकेशन टैब पर:
इस DevTool इंटिग्रेशन के बारे में ज़्यादा पढ़ें.
सर्वर से जुड़े सबसे सही तरीके और समस्या हल करना
हमारा सुझाव है कि जारी करने वाले और रिडीम करने वाले सर्वर के सही तरीके से काम करने के लिए, यहां दिए गए सबसे सही तरीके अपनाएं. इससे यह पक्का किया जा सकेगा कि आपको पीएसटी के लिए ऐक्सेस, सुरक्षा, लॉगिन या ट्रैफ़िक से जुड़ी किसी भी समस्या का सामना न करना पड़े.
- आपके एंडपॉइंट पर TLS 1.3 या 1.2 का इस्तेमाल करके, सुरक्षित क्रिप्टोग्राफ़ी लागू किया जाना चाहिए.
- आपका इन्फ़्रास्ट्रक्चर, ट्रैफ़िक के वैरिएबल वॉल्यूम को मैनेज करने के लिए तैयार होना चाहिए. इसमें बढ़ोतरी में बढ़ोतरी भी शामिल है.
- पक्का करें कि आपकी कुंजियां पूरी तरह सुरक्षित हैं. साथ ही, ये ऐक्सेस कंट्रोल की नीति, कुंजियों को मैनेज करने की रणनीति, और कारोबार को चालू रखने की योजना के मुताबिक होनी चाहिए.
- अपने स्टैक में निगरानी से जुड़ी मेट्रिक जोड़ें, ताकि यह पक्का किया जा सके कि प्रोडक्शन ट्रैक के बाद, इस्तेमाल, रुकावटों, और परफ़ॉर्मेंस की समस्याओं को समझने के लिए, आपको जानकारी दिखेगी.
ज़्यादा जानकारी
- डेवलपर के दस्तावेज़ों की समीक्षा करें:
- पीएसटी और इसकी सुविधाओं के बारे में जानने के लिए, खास जानकारी वाला लेख पढ़ें.
- पीएसटी के बारे में बताने वाला वीडियो देखें.
- पीएसटी डेमो आज़माएं.
- इसके बारे में ज़्यादा जानकारी पाने के लिए, एपीआई का जानकारी देने वाला टूल भी पढ़ें.
- एपीआई की मौजूदा जानकारी के बारे में ज़्यादा पढ़ें.
- GitHub की समस्याओं या W3C कॉल की मदद से, बातचीत में योगदान दें.
- किसी भी शब्दावली को बेहतर ढंग से समझने के लिए, प्राइवसी सैंडबॉक्स की शब्दावली देखें.
- 'ऑरिजिन ट्रायल' या 'Chrome फ़्लैग' जैसे Chrome के सिद्धांतों के बारे में ज़्यादा जानने के लिए, goo.gle/cc पर उपलब्ध छोटे वीडियो और लेख देखें.