अपनी API-की का प्रबंधन करना
कंसोल में API & Webhooks के तहत अपनी API-की ढूंढें, उसे सर्वर-साइड रखें, टेस्टिंग के लिए अलग sandbox एप्लिकेशन इस्तेमाल करें, और 401 व 403 एरर ठीक करें।
API & Webhooks, जो उसी एप्लिकेशन तक सीमित है जिसे आपने चुना है। हर एप्लिकेशन की एक ही की होती है, और की ही एनवायरनमेंट है - किसी लाइव एप्लिकेशन पर कोई अलग टेस्ट की नहीं होती। यह सर्वर-साइड सीक्रेट है: कभी भी इसे फ्रंटएंड कोड या ऐप बंडल में न रखें।
आपकी API-की कंसोल के साइडबार में API & Webhooks के तहत मिलती है, और यह उसी एप्लिकेशन तक सीमित है जिस पर आप काम कर रहे हैं। इसे पासवर्ड की तरह समझें - यह उस एप्लिकेशन की तरफ़ से पूरी API पहुंच देती है।
#अपनी की ढूंढना
- Business Console में लॉग इन करें
business.didit.me पर जाएं और साइन इन करें।
- अपना एप्लिकेशन चुनें
कंसोल के ऊपर मौजूद ड्रॉपडाउन से वह एप्लिकेशन चुनें जो आपको चाहिए। हर एप्लिकेशन की अपनी अलग की होती है।
- API & Webhooks खोलें
आपकी API की यहीं मिलती है, आपके webhook डेस्टिनेशन और उनके सिग्निंग सीक्रेट के साथ।
- Create API key नई की जारी करता है; की हर एप्लिकेशन के लिए अलग होती है।
- सीक्रेट यहां सिर्फ़ एक बार दिखता है - इसे अपने सीक्रेट स्टोर में कॉपी कर लें।
- Rotate secret की का नाम बदले बिना सीक्रेट बदल देता है।
- Last used से पता चलता है कि कोई की अभी काम में है या भुला दी गई है, इसे रिवोक करने से पहले।
#API-की और सिग्निंग सीक्रेट अलग-अलग चीज़ें हैं
यह साफ़ कह देना ज़रूरी है, क्योंकि इन्हें मिला देने से उलझाने वाली एरर आती हैं:
| यह किसलिए है | कहां | |
|---|---|---|
| API-की | x-api-key हेडर में, Didit को की जाने वाली आपकी कॉल्स को ऑथेंटिकेट करना | हर एप्लिकेशन के लिए |
| Webhook सिग्निंग सीक्रेट | यह पुष्टि करना कि आया हुआ webhook सच में Didit से आया है | हर डेस्टिनेशन के लिए |
सिग्निंग सीक्रेट को अपनी API-की की तरह भेजने पर 401 आता है। अपनी API-की से किसी webhook को वेरिफ़ाई करने पर सिग्नेचर मैच नहीं होता। दोनों ग़लतियां आम हैं।
आपकी API-की एक सीक्रेट है। इसे कभी भी फ्रंटएंड कोड, किसी सार्वजनिक रिपॉज़िटरी, या मोबाइल ऐप बंडल में न डालें - इसे सिर्फ़ सर्वर-साइड रखें। किसी शिप किए गए ऐप बंडल में मौजूद की वह की है जो किसी हमलावर के पास पहुंच चुकी है। देखें API ऑथेंटिकेशन।
#टेस्टिंग के लिए की लेना
आप प्रोडक्शन के ख़िलाफ़ टेस्ट नहीं करते। sandbox मोड में एक अलग एप्लिकेशन बनाएं - sandbox सेशन हर बाहरी चेक को मॉक करते हैं, कभी बिल नहीं होते, और असली उपयोगकर्ता डेटा को छूते तक नहीं। बनाते समय इसकी की इस्तेमाल करें, और असली सत्यापन के लिए एक अलग लाइव एप्लिकेशन बनाए रखें।
लाइव एप्लिकेशन पर कोई "टेस्ट की" नहीं होती। की ही एनवायरनमेंट है, इसलिए अपने सीक्रेट रखने वाली जगह पर अपनी कीज़ को साफ़-साफ़ नाम देना समझदारी है। देखें sandbox में टेस्टिंग।
#अपनी की रोटेट करना
अगर लगे कि कोई की उजागर हो गई है, तो उसे उसी API & Webhooks पेज से फिर से जनरेट करें। दोबारा जनरेट करने पर पुरानी की तुरंत बेकार हो जाती है, इसलिए जहां-जहां इस्तेमाल हो रही है वहां पहले उसे बदल लें - वरना बटन दबाते ही आपका प्रोडक्शन ट्रैफ़िक फेल होने लगेगा।
तय समय पर की रोटेट करना अच्छी आदत है। इसे एक क्लिक की तरह नहीं, डिप्लॉय की तरह प्लान करें।
#401 और 403 ठीक करना
| एरर | वजह | उपाय |
|---|---|---|
401 | की ग़ायब है, गलत फ़ॉर्मेट में है, या दोबारा जनरेट की जा चुकी है | उस एप्लिकेशन के लिए API & Webhooks से मौजूदा की कॉपी करें। इधर-उधर स्पेस या कोट्स तो नहीं आ गए, और कहीं आपने गलती से सिग्निंग सीक्रेट तो नहीं पेस्ट कर दिया, यह देखें |
403 | की सही है पर यह कॉल इजाज़त में नहीं है | आमतौर पर ग़लत एप्लिकेशन, किसी लाइव की पर sandbox-only फ़ील्ड (या उल्टा), आपकी की के पास न होने वाली कोई परमिशन, या आपके अकाउंट पर बंद कोई फीचर |
किसी ख़ास वर्कफ़्लो पर 403 का लगभग हमेशा मतलब है कि की उस एप्लिकेशन से अलग किसी एप्लिकेशन की है जिसके पास वह वर्कफ़्लो है। कंसोल में एप्लिकेशन बदलें और उसकी की कॉपी करें। पूरी जानकारी: API एरर और उनका मतलब।
#की क्या कर सकती है, यह सीमित करना
अगर आपकी ज़रूरत यह है कि की सिर्फ़ कुछ ख़ास डेटा कैटेगरी तक पहुंच सके - मसलन किसी सर्विस को डॉक्यूमेंट की इमेज तक पहुंचने से रोकना - तो यह की की किसी सेटिंग का नहीं, बल्कि परमिशन का सवाल है, और यह आपके अकाउंट पर निर्भर करता है कि क्या उपलब्ध है। यह मान लेने के बजाय कि कोई की बेरोकटोक है या रोकी हुई है, सपोर्ट से पूछें - दोनों ही अंदाज़े उल्टी दिशा में जोखिम भरे हैं।
#आपकी टीम में कौन कीज़ देख सकता है
की दिखना रोल पर निर्भर करता है। Developer रोल में API-की शामिल है; Reader में नहीं। अगर कोई टीम सदस्य यह पेज नहीं ढूंढ पा रहा, तो रिपोर्ट करने से पहले उसका रोल जांचें। देखें टीम सदस्यों को आमंत्रित करना और रोल तय करना।
#हर कॉल लॉग होती है
API-की से की गई रिक्वेस्ट Audit Logs में किसी व्यक्ति के बजाय उस एप्लिकेशन के नाम पर दर्ज होती हैं - और यही वजह है कि कई सर्विस में एक ही की शेयर करने से किसी घटना की जांच मुश्किल हो जाती है। हर इस्तेमाल करने वाले के लिए अलग की रखना समझना आसान बनाता है। देखें ऑडिट लॉग का इस्तेमाल।