Google-विक्रेता साझा पहचानकर्ता प्रॉपर्टी

बैकग्राउंड

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

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

शेयर किए गए आइडेंटिफ़ायर की प्रॉपर्टी

शेयर किए गए आइडेंटिफ़ायर के लिए ज़रूरी प्रॉपर्टी, पिछले अनुभव और तकनीकी समस्याओं की वजह से जनरेट होती हैं. ये ऐसी तकनीकी समस्याएं होती हैं जो शेयर किए गए आइडेंटिफ़ायर में इन प्रॉपर्टी की कमी की वजह से आती हैं.

Google और बाहरी पार्टनर के बीच इंटिग्रेशन के लिए, यह ज़रूरी है कि इस्तेमाल किए गए शेयर किए गए आइडेंटिफ़ायर में ये प्रॉपर्टी हों:

  1. दुनिया भर में यूनीक होना चाहिए: शेयर किया गया यह आइडेंटिफ़ायर, Google उपयोगकर्ता और जारी करने वाले खाते के बीच एक लिंक के बारे में बताने वाला होना चाहिए. एक ही जारी करने वाले के लिए, एक जैसे वैल्यू वाले दूसरे शेयर किए गए आइडेंटिफ़ायर नहीं होने चाहिए.
  2. न पहचाने जाने वाले आइडेंटिफ़ायर: शेयर किए गए इन आइडेंटिफ़ायर के पास, लोगों की तरफ़ से कार्रवाई करने की अनुमति होती है. इसलिए, यह ज़रूरी है कि कोई तीसरा पक्ष, शेयर की गई आइडेंटिफ़ायर वैल्यू का अनुमान न लगा पाए.
  3. रद्द किया जा सकने वाला होना: यह ज़रूरी है कि शेयर किए गए आइडेंटिफ़ायर को उपयोगकर्ता रद्द कर सकता है. यह सहमति रद्द होने पर, आने वाले समय में शेयर की गई आइडेंटिफ़ायर वैल्यू का इस्तेमाल नहीं होना चाहिए. इस प्रॉपर्टी में कुछ कोरोलेरी प्रॉपर्टी हैं, जो इस तरह हैं:
    • किसी भी खाते की ऐसी प्रॉपर्टी पर आधारित नहीं है जिसे बदला नहीं जा सकता: अगर शेयर किए गए आइडेंटिफ़ायर की वैल्यू, जारी करने वाले के खाते या Google खाते की ऐसी प्रॉपर्टी पर आधारित है जिसे बदला नहीं जा सकता, तो शेयर किए गए आइडेंटिफ़ायर का फिर से इस्तेमाल करने से उस शेयर किए गए आइडेंटिफ़ायर की वैल्यू दोबारा बनी रहेगी (इसलिए, रद्द होने की वजह से वापस ऐसा होगा). इसलिए, शेयर किए गए आइडेंटिफ़ायर की वैल्यू, फ़ोन नंबर की प्रॉपर्टी या फ़ोन नंबर की नहीं होनी चाहिए (e.
    • सिर्फ़ <Google Account, Partner Account> नहीं होना चाहिए: सहमति रद्द करने के लिए, कुछ और वैल्यू (जैसे कि समय) भी होनी चाहिए.
  4. खाते के दोनों ओर मौजूद एक से ज़्यादा लिंक की अनुमति दें: यह ज़रूरी है कि शेयर किए गए आइडेंटिफ़ायर की वैल्यू बनाने से, Google के किसी उपयोगकर्ता के लिए, एक से ज़्यादा बैंक खातों को लिंक करना या एक से ज़्यादा Google खाते को रद्द करने की क्षमता की तरह, इसमें कुछ और मुख्य बातें होती हैं:
    • ध्यान रखें, किसी भी खाते की ऐसी प्रॉपर्टी पर आधारित नहीं होती जिसे बदला न जा सके: ऐसा नहीं करने पर, शेयर किए गए आइडेंटिफ़ायर की वैल्यू वही होगी जो एक Google उपयोगकर्ता ने कई बैंक खातों को जोड़ा है (अगर शेयर किए गए आइडेंटिफ़ायर की वैल्यू Google खाते के आधार पर है) या जब कई Google खाते एक ही बैंक खाते से लिंक किए गए हों (अगर शेयर किए गए आइडेंटिफ़ायर की वैल्यू बैंक खाते की प्रॉपर्टी पर आधारित थी)
  5. लंबे समय तक इस्तेमाल किया जा सकता है: शेयर किया गया आइडेंटिफ़ायर सिर्फ़ सुरक्षित कॉन्टेक्स्ट (Google और वेंडर के बीच के इंटिग्रेशन, जो कनेक्शन लेवल और ऐप्लिकेशन लेवल, दोनों के लिए सुरक्षा का इस्तेमाल करता है, जैसे कि PGP, म्यूचुअल एसएसएल वगैरह) के लिए ही मान्य होता है. इसलिए, इसे सुरक्षित रखने के लिए कम लाइफ़ साइकल की ज़रूरत नहीं होती. Google की प्राथमिकता है कि शेयर किए गए आइडेंटिफ़ायर की समयसीमा खत्म न हो. हालांकि, अगर किसी वेंडर को डेटा ऐक्सेस करने की समयसीमा खत्म करनी है, तो यह लंबी समयावधि होनी चाहिए, जैसे कि एक साल से ज़्यादा की समयसीमा.

शेयर की गई अन्य आइडेंटिफ़ायर प्रॉपर्टी का सुझाव दिया जाता है:

  1. Base64: इसकी मदद से, इंटिग्रेशन में ट्रांसपोर्ट और वैल्यू के बारे में https से आसानी से बताया जा सकता है.
  2. कम से कम लंबाई: हमारा सुझाव है कि Base64 कोड में बदलने से पहले, कम से कम 27 अंक रखें.

क्या गलत हो सकता है?

ज़रूरी प्रॉपर्टी को समझने में पाठकों की मदद करने के लिए, यहां कुछ केस स्टडी दी गई हैं. इनमें बताया गया है कि जब इन प्रॉपर्टी का पालन नहीं किया जाता है, तब समस्याओं का सामना करना पड़ता है.

शेयर किए गए आइडेंटिफ़ायर से जुड़ी केस स्टडी

केस स्टडी #1: फ़ोन नंबर रीसाइकल करना

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

जारी करने वाले ने कई शेयर किए गए आइडेंटिफ़ायर की प्रॉपर्टी का उल्लंघन किया है. इनमें से मुख्य प्रॉपर्टी #1 है. फ़ोन नंबर जैसी चीज़ें एक उपयोगकर्ता से दूसरे उपयोगकर्ता पर माइग्रेट हो सकती हैं, इसलिए वे किसी खास स्नैपशॉट के दौरान ही यूनीक होती हैं.

केस स्टडी #2: चिपकाने का तरीका

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

केस स्टडी #3: खराब कर्मचारी

ऊपर दी गई "चिपकाने" की घटना के बाद, Google/पार्टनर में मौजूद बुरे मकसद से काम करने वाले को पता चलता है कि शेयर किया गया आइडेंटिफ़ायर सिर्फ़ उपयोगकर्ता का खाता आईडी है. इसलिए, अगर वह किसी और के खाता आईडी को उनके शेयर किए गए आइडेंटिफ़ायर मान में डाल सकता है, तो वह उस व्यक्ति के खाते से खरीदारी कर सकता है. प्रॉपर्टी #2 के उल्लंघन ने इस गलती से पेस्ट को किसी एक उपयोगकर्ता के लिए सुरक्षा से कहीं ज़्यादा बना दिया है -- यह हर उपयोगकर्ता के लिए सुरक्षा की कमी है.

केस स्टडी #4: रोटेशन

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

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