आपका वेब ऐप शायद ऐसे काम कर रहा है जिन्हें आपने कभी वास्तव में डीबग नहीं किया। यूज़र के कुछ भी क्लिक करने से पहले pages prerender हो रहे हैं, form submissions ऑफलाइन रहते हुए चुपचाप queue में जा रहे हैं, push notifications एक सोए हुए service worker पर आ रही हैं, sessions cryptographically hardware keys से bound हैं — यह सब Chrome के background service APIs के ज़रिए होता है, पूरी तरह अदृश्य रूप से। Chrome DevTools का Background Services पैनल वह जगह है जहाँ आप अंततः यह सब देख पाते हैं।
दो सवाल लगातार आपस में घुलमिल जाते हैं: “TLS टर्मिनेशन क्या है” और “क्या SSL ट्रांसपोर्ट लेयर की चीज़ है?” लोग मान लेते हैं कि दूसरे का जवाब साफ़-साफ़ हाँ है — इसका नाम ही तो शाब्दिक रूप से Transport Layer Security है, है ना? खैर। इस नामकरण ने बहुत से समझदार लोगों को भी चकमा दिया है, और यह उलझन सीधे इस बात में रिस जाती है कि लोग टर्मिनेशन के बारे में कैसे सोचते हैं। तो मुझे दोनों को सुलझाने दीजिए, क्योंकि एक बार जब लेयर वाला सवाल समझ में आ जाता है, तो टर्मिनेशन जादू जैसा लगना बंद कर देता है।
आप एक API एंडपॉइंट /api/orders/1042 एक्सपोज़ करते हैं। वह इंटीजर किसी को भी — एक प्रतिस्पर्धी, एक हमलावर, एक जिज्ञासु उपयोगकर्ता — बिल्कुल बता देता है कि आपके पास कितने ऑर्डर हैं। नंबर को 1041 में बदलें, तो पिछला ऑर्डर मिल जाता है। इसे 1 में बदलें, तो पहला ऑर्डर मिल जाता है। कोई auth bypass की ज़रूरत नहीं। ID खुद ही जानकारी का रिसाव है।
यही एक पैराग्राफ में अनुक्रमिक ID की समस्या है। UUID इसे ठीक करने के लिए मौजूद है — और कुछ अन्य चीज़ें जो स्केल पर मायने रखती हैं।