कभी एक्सपायर न होने वाली API कुंजियों की समस्या
कई साल पहले जारी की गई कुंजी, जिसे कभी रोटेट नहीं किया गया और जो आज भी मान्य है, कोई सुविधा नहीं है। यह एक जोखिम है जिसे सालों से किसी ने वास्तव में देखा तक नहीं।
हमने सबसे पहले ब्राउज़र SDK क्यों नहीं बनाया
ब्राउज़र SDK माँगना आसान है, लेकिन जियोकोडिंग या IP लुकअप API असल में जो काम करता है, उसके बड़े हिस्से के लिए यह सचमुच एक बुरा विचार है। किसी IP पते को लोकेशन में बदलना इसीलिए सार्थक है क्योंकि यह सर्वर पर होता है, जहाँ अनुरोध का असली स्रोत दिखाई देता है। वही लुकअप किसी विज़िटर के ब्राउज़र में चलने वाले क्लाइंट-साइड JavaScript में डाल दें, तो आपने इंटीग्रेशन को ज़्यादा सुविधाजनक नहीं बनाया। आपने एक प्रमाणित API कुंजी को अनुरोध के पूरे रास्ते की उस इकलौती जगह पर पहुँचा दिया है जहाँ कोई भी डेवलपर टूल खोलकर उसे पढ़ सकता है।
इसीलिए हमने सादे HTTP सपोर्ट और कम्पैटिबिलिटी होस्ट से पहले ब्राउज़र SDK को प्राथमिकता नहीं दी। X-API-Key हेडर, Bearer टोकन, HTTP Basic auth या क्वेरी पैरामीटर के रूप में स्वीकार की गई कुंजी हर होस्ट पर एक जैसी काम करती है, और उसे वहीं से कॉल किया जा सकता है जहाँ आपका सर्वर-साइड कोड पहले से मौजूद है: कोई बैकएंड सर्विस, कोई सर्वरलेस फ़ंक्शन, कोई बैच जॉब, कोई भी ऐसी जगह जहाँ अनुरोध के पास पहले से आपके नियंत्रण वाले इन्फ्रास्ट्रक्चर से शुरू होने की वजह हो, न कि किसी ऐसे ब्राउज़र टैब से जो आपके नियंत्रण में नहीं है।
IP जियोलोकेशन तो खास तौर पर सिर्फ़ सर्वर-साइड ही समझ में आता है। लुकअप का पूरा मूल्य अनुरोध करने वाले असली IP पते को पहचानने से आता है, और ज़्यादातर सार्थक उपयोगों में, जैसे धोखाधड़ी की जाँच, स्थानीयकरण, और वह एनालिटिक्स जिसे आप बेचने के बजाय खुद नियंत्रित करते हैं, यह वहीं होना चाहिए जहाँ वह IP पता प्रामाणिक है: आपका सर्वर, जो अनुरोध सीधे प्राप्त करता है। ब्राउज़र का माहौल नहीं, जहाँ क्लाइंट-साइड कॉल जो “IP” बताएगी वह या तो अप्रासंगिक है या आसानी से नकली बनाया जा सकता है।
टाइप किए गए पते की जियोकोडिंग इतनी साफ़ तौर पर सिर्फ़ सर्वर का काम नहीं है, और यह चाहने का एक असली तर्क है कि पता ऑटोकम्प्लीट किसी फ़ॉर्म में, सीधे ब्राउज़र में, पहले आपके अपने बैकएंड से राउंड ट्रिप किए बिना, तुरंत प्रतिक्रिया दे। हम इस पैटर्न के आगे चलकर मौजूद होने के ख़िलाफ़ नहीं हैं। हम इसे पहले और मुख्य इंटीग्रेशन रास्ते के रूप में बनाने के ख़िलाफ़ हैं, उस सादे सर्वर-साइड HTTP एक्सेस से पहले, जिसकी ज़्यादातर असली उपयोगों को, जैसे चेकआउट फ़्लो, शिपिंग कैलकुलेटर और धोखाधड़ी की जाँच को, वास्तव में ज़रूरत होती है और जिसके लिए किसी क्रेडेंशियल को सार्वजनिक करने की ज़रूरत नहीं पड़ती।
हम जिस व्यापक पैटर्न का विरोध कर रहे हैं, वह है “ब्राउज़र SDK देता है” को ऐसा चेकबॉक्स मानना जो हर API के पास होना चाहिए, इस बात की परवाह किए बिना कि उस खास तरह के डेटा तक क्लाइंट-साइड पहुँच समझ में आती है या नहीं। ऐसे लुकअप के लिए जहाँ सर्वर-साइड संदर्भ ही पूरा मुद्दा है, ब्राउज़र SDK ज़्यादातर बस एक मार्केटिंग सवाल का जवाब देता है, “क्या यह आधुनिक और सुविधाजनक दिखता है”, और इसकी कीमत एक असली सुरक्षा सवाल से चुकाई जाती है, “यह क्रेडेंशियल आख़िर कहाँ रहेगा।” हम पहले सुरक्षा के सवाल का जवाब देना चाहेंगे और सुविधा को उसके बाद आने देंगे, उल्टा नहीं।
इसका मतलब यह नहीं कि आगे चलकर कोई हल्का, ब्राउज़र के अनुकूल टूल नहीं आ सकता, जो खास तौर पर उन मामलों तक सीमित हो जहाँ क्लाइंट-साइड उपयोग सचमुच समझ में आता है, जैसे कोई फ़ॉर्म ऑटोकम्प्लीट जिसे काम करने के लिए कभी आपके खाते के असली क्रेडेंशियल की ज़रूरत न हो। बस वह ऐसी पहली चीज़ नहीं होनी चाहिए जिस पर हम किसी ग्राहक से भरोसा करने को कहें, उस सादे HTTP रास्ते से पहले जो पहले से ही ज़्यादातर असली इंटीग्रेशन को सुरक्षित रूप से कवर करता है।