पैनल का मालिक जब सुरक्षा के बारे में सोचता है, तो बाहर से होने वाले हमले के बारे में सोचता है: लोड, पासवर्ड अनुमान, कमज़ोरी खोजने वाले स्कैनर। पर खुले API वाले पैनल का एक दूसरा दरवाज़ा भी होता है, और वह पूरी तरह जायज़ दिखता है: अनुरोध वैध कुंजी के साथ, आपके ही पंजीकृत ग्राहक की तरफ़ से आते हैं और सामान्य ट्रैफ़िक से अलग नहीं दिखते। यहाँ देखते हैं कि एक बायर एक ही curl पंक्ति से आपके पैनल का क्या कर सकता है, इसे कौन-सी जाँचें रोकती हैं, और बटन छिपाने से कुछ क्यों नहीं होता।

वह हमला जिसके पास आपकी कुंजी है

आम हमले से फ़र्क़ बुनियादी है, और बाक़ी सब उसी से निकलता है। बाहरी हमला दरवाज़े पर ही रोका जाता है: ट्रैफ़िक छननी, लॉगिन कोशिशों की सीमा, कैप्चा - इसके लिए पैनल सुरक्षा पर अलग लेख है। यहाँ उलटा है: ट्रैफ़िक जायज़ है, कुंजी असली है, ग्राहक मौजूद है, और दरवाज़े की कोई छननी इस अनुरोध को नहीं रोकेगी।

और अक्सर इसमें बुरी नीयत होती भी नहीं। व्यवहार में तीन स्रोत हैं:

मुख्य नियम: इंटरफ़ेस कुछ भी नहीं बचाता

ठोकर सबसे ज़्यादा यहीं लगती है। बटन छिपाना, सेवा को स्टोरफ़्रंट से हटाना, कोई हिस्सा बंद करना - ये सब सिर्फ़ वह बदलते हैं जो ब्राउज़र देखता है। कुंजी वाला ग्राहक ब्राउज़र खोलता ही नहीं।

हमारे कोर में यह नियम तीन अलग सर्वर जाँचों से बँधा है, और हर एक की टिप्पणी में वही बात लिखी है: उसके बिना रोक एक curl पंक्ति से पार हो जाती।

और चौथी, सबसे आम बात। ऑर्डर की सारी जाँचें - सेवा उपलब्ध है या नहीं, मात्रा की सीमाएँ, ईमेल पुष्टि, सेवा का प्रकार, बैलेंस पूरा पड़ता है या नहीं - एक ही जगह रहनी चाहिए जहाँ से सारे रास्ते गुज़रें: स्टोरफ़्रंट का फ़ॉर्म भी, API भी, और मेहमान चेकआउट भी। उन्हें बुलाने वालों में बाँटना ठीक नहीं: देर-सबेर एक रास्ता वह मान लेगा जो दूसरा ठुकराता है, और यह फ़र्क़ चुपचाप बनेगा।

नक़ली और कचरा ऑर्डर

दूसरी परत वे ऑर्डर हैं जो नियम से वैध हैं पर आपको कुछ नहीं देते। हर एक प्रोवाइडर तक जाता है, उसकी सीमाएँ खाता है और सुलझाने में आपका वक़्त लेता है।

लिमिट जला देना

तीसरी परत सबसे कष्टकर है, क्योंकि यह एक ग्राहक पर नहीं, सब पर एक साथ पड़ती है। बिना रुके चक्कर में स्टेटस पूछने वाली स्क्रिप्ट साझा अनुरोध बजट खा जाती है, और उसके साथ बाक़ी सारे बायर अटक जाते हैं।

कुछ अंदाज़े। हमारे यहाँ ग्राहक API मिनट में सौ से कुछ ज़्यादा अनुरोधों तक सीमित है और एडमिन API क़रीब तीन गुना; यह असंगति नहीं है: ग्राहक कुंजी आम तौर पर कोई इंसान या छोटी स्क्रिप्ट चलाती है, जबकि एडमिन API पर रोबोट आता है और झुंड में। प्रचलित इंजन वाले पैनलों में सीमा और सख़्त है - प्रति पैनल क़रीब पाँच अनुरोध प्रति सेकंड, और असली इंटीग्रेशन में उससे टकराना सोच से आसान है।

दो नतीजे जिनकी पहले से योजना कम ही बनती है:

इसका सही जवाब रोक नहीं, बल्कि बैच मेथड और साफ़ दस्तावेज़ हैं। सौ तक नंबरों का स्टेटस एक झुंड में पूछना वही काम करता है जो एक-एक ऑर्डर का चक्कर, पर दोनों पक्षों के लिए सौ गुना सस्ता। अगर आपके बायर यह नहीं जानते, तो वे एक-एक करके पीटते रहेंगे।

कुंजियों का क्या करें

यह सब दिखेगा कैसे

भीतर से होने वाले दुरुपयोग की असल दिक़्क़त यह है कि वह दिक़्क़त जैसा दिखता ही नहीं: ऑर्डर बनते हैं, पैसा चलता है, पैनल काम करता है। कम से कम इतना होना चाहिए:

निचोड़

खुला API कोई छेद नहीं, पैनल के बढ़ने का मुख्य रास्ता है: कुंजी वाला बायर वह हिस्सा लाता है जो हाथ से कभी नहीं जुटेगा, और API इसीलिए बनाया जाता है। बस उसकी हिफ़ाज़त वैसे नहीं होती जैसे किसी वेबसाइट की। सारे नियम सर्वर पर रहते हैं, सारे रास्ते एक ही जाँचों से गुज़रते हैं, सीमाएँ पहले से घोषित होती हैं, बैच मेथड दस्तावेज़ में होते हैं, और कुंजी एक क्लिक में नई हो जाती है। छिपा हुआ बटन कुछ नहीं बचाता, और इसे ठोकर खाकर सीखने से पहले मान लेना सस्ता है। कुंजी किसे और क्यों देनी है, यह रीसेलर के लिए पैनल API लेख में है।

यह किसी ज़िंदा पैनल पर कैसे चलता है, इसे बिना ख़र्च के देखा जा सकता है: हमारे अपने कैटलॉग से जाने वाले ऑर्डर गिने ही नहीं जाते, और बाहरी प्रोवाइडरों पर महीने के पहले 100 ऑर्डर मुफ़्त हैं। कुंजी तुरंत मिल जाती है, यानी अपनी स्क्रिप्ट पहले ही दिन उस पर चलाई जा सकती है।