कंसोल में डेवलपर्स, API कुंजियाँ के तहत हर सर्विस के लिए अलग की बनाएं जिसमें सिर्फ़ ज़रूरी पहुंच हो, कीज़ सर्वर-साइड रखें, और 401 व 403 एरर ठीक करें।
डेवलपर्स → API कुंजियाँ, जो उसी एप्लिकेशन तक सीमित है जिसे आपने चुना है। हर एप्लिकेशन की एक प्राथमिक की होती है, और आप और कीज़ बना सकते हैं, हर सर्विस के लिए एक, जिनमें से हर एक की अपनी पहुंच और समय-सीमा होती है। की एक सर्वर-साइड सीक्रेट है: कभी भी इसे फ्रंटएंड कोड या ऐप बंडल में न रखें।
आपकी API-कीज़ कंसोल में डेवलपर्स → API कुंजियाँ के तहत मिलती हैं, और ये उसी एप्लिकेशन तक सीमित हैं जिस पर आप काम कर रहे हैं। हर की को पासवर्ड की तरह समझें: यह उस एप्लिकेशन की तरफ़ से API पहुंच देती है।
#अपनी की ढूंढना
- Business Console में लॉग इन करें
business.didit.me पर जाएं और साइन इन करें।
- अपना एप्लिकेशन चुनें
साइडबार के ऊपर मौजूद एप्लिकेशन कार्ड से एप्लिकेशन चुनें। हर एप्लिकेशन की अपनी अलग कीज़ होती हैं।
- डेवलपर्स, फिर API कुंजियाँ खोलें
कुंजियाँ टैब हर की की लिस्ट दिखाता है, प्राथमिक की से शुरू करके, साथ में उसकी पहुंच, उसका आखिरी इस्तेमाल कब हुआ और उसकी समय-सीमा कब खत्म होती है।
#की बनाना
Didit को कॉल करने वाली हर सर्विस को उसकी अपनी की दें, ताकि आप देख सकें कि हर एक क्या करती है और उसे अकेले रद्द कर सकें।
- कुंजी बनाएँ दबाएं
डेवलपर्स → API कुंजियाँ पर।
- इसे नाम दें और एनवायरनमेंट चुनें
की का नाम उस सर्विस के नाम पर रखें जो इसे इस्तेमाल करेगी, लाइव (असली सत्यापन, जिनका बिल बनता है) या सैंडबॉक्स (टेस्ट डेटा, कभी बिल नहीं बनता; की आपके संगठन के Sandbox एप्लिकेशन में बनती है) चुनें, और चुनें कि इसकी समय-सीमा कब खत्म हो: कभी नहीं, 30 दिन, 90 दिन या एक साल बाद, या आपकी चुनी हुई तारीख पर।
- इसकी पहुंच चुनें
पूर्ण एक्सेस सब कुछ पढ़ता और लिखता है, आपके अपने बैकएंड के लिए। केवल पढ़ने योग्य सेशन, निर्णय और मीडिया देखता है पर कुछ बदल नहीं सकता, ऐसे पार्टनर के लिए जिसे सिर्फ़ नतीजे चाहिए। कस्टम से आप हर रिसोर्स के लिए अलग से चुन सकते हैं। जब सर्विस को सिर्फ़ निर्णय चाहिए, न कि ID इमेज, सेल्फ़ी, वीडियो या PDF रिपोर्ट, तब मीडिया शामिल करें से टिक हटा दें।
- जांचें और सीक्रेट कॉपी करें
पूरा सीक्रेट सिर्फ़ एक बार दिखता है, जब की बनती है। इसे सीधे अपने सीक्रेट मैनेजर में कॉपी करें।
प्राथमिक की एप्लिकेशन का मूल सीक्रेट है। इसके पास हमेशा पूरी पहुंच होती है और इसे रोटेट किया जा सकता है, पर रद्द नहीं किया जा सकता।
#API-की और सिग्निंग सीक्रेट अलग-अलग चीज़ें हैं
यह साफ़ कह देना ज़रूरी है, क्योंकि इन्हें मिला देने से उलझाने वाली एरर आती हैं:
| यह किसलिए है | कहां | |
|---|---|---|
| API-की | x-api-key हेडर में, Didit को की जाने वाली आपकी कॉल्स को ऑथेंटिकेट करना | हर एप्लिकेशन के लिए, जितनी आपको चाहिए |
| Webhook सिग्निंग सीक्रेट | यह पुष्टि करना कि आया हुआ webhook सच में Didit से आया है | हर webhook एंडपॉइंट के लिए |
सिग्निंग सीक्रेट को अपनी API-की की तरह भेजने पर 401 आता है। अपनी API-की से किसी webhook को वेरिफ़ाई करने पर सिग्नेचर मैच नहीं होता। दोनों ग़लतियां आम हैं।
आपकी API-की एक सीक्रेट है। इसे कभी भी फ्रंटएंड कोड, किसी सार्वजनिक रिपॉज़िटरी, या मोबाइल ऐप बंडल में न डालें - इसे सिर्फ़ सर्वर-साइड रखें। किसी शिप किए गए ऐप बंडल में मौजूद की वह की है जो किसी हमलावर के पास पहुंच चुकी है। देखें API ऑथेंटिकेशन।
#टेस्टिंग के लिए की लेना
आप प्रोडक्शन के ख़िलाफ़ टेस्ट नहीं करते। कंसोल को सैंडबॉक्स पर स्विच करें और वहां एक की बनाएं, या की बनाते समय एनवायरनमेंट के तौर पर सैंडबॉक्स चुनें। Sandbox सेशन हर बाहरी चेक को मॉक करते हैं, कभी बिल नहीं होते, और असली उपयोगकर्ता डेटा को छूते तक नहीं।
एक की एक ही एप्लिकेशन की होती है, और उसके साथ उस एप्लिकेशन के एनवायरनमेंट की: sandbox की कभी लाइव सत्यापन नहीं बनाती, और लाइव की कभी sandbox सत्यापन नहीं बनाती। अपने सीक्रेट रखने वाली जगह पर अपनी कीज़ को साफ़-साफ़ नाम देना समझदारी है। देखें sandbox में टेस्टिंग।
#अपनी की रोटेट करना
अगर लगे कि कोई की उजागर हो गई है, तो उसे खोलें और कुंजी बदलें चुनें। आपको एक नया सीक्रेट मिलता है, और पुराना 24 घंटे तक काम करता रहता है, ताकि आप बिना डाउनटाइम के नया सीक्रेट डिप्लॉय कर सकें। उसके बाद, पुराने सीक्रेट वाली हर रिक्वेस्ट पर 401 आता है।
अगर किसी की को अभी के अभी काम करना बंद करना है, तो इसके बजाय कुंजी रद्द करें चुनें। रद्द करने से वह तुरंत बंद हो जाती है और इसे पूर्ववत नहीं किया जा सकता। प्राथमिक की को सिर्फ़ रोटेट किया जा सकता है।
तय समय पर की रोटेट करना अच्छी आदत है। इसे एक क्लिक की तरह नहीं, डिप्लॉय की तरह प्लान करें।
#401 और 403 ठीक करना
| एरर | वजह | उपाय |
|---|---|---|
401 | की ग़ायब है, गलत फ़ॉर्मेट में है, उसकी समय-सीमा खत्म हो चुकी है, रद्द हो चुकी है, या 24 घंटे से ज़्यादा पहले रोटेट की जा चुकी है | उस एप्लिकेशन के लिए डेवलपर्स → API कुंजियाँ के तहत की जांचें। इधर-उधर स्पेस या कोट्स तो नहीं आ गए, और कहीं आपने गलती से सिग्निंग सीक्रेट तो नहीं पेस्ट कर दिया, यह देखें |
403 | की सही है पर यह कॉल इजाज़त में नहीं है | आमतौर पर ग़लत एप्लिकेशन, किसी लाइव की पर sandbox-only फ़ील्ड (या उल्टा), ऐसी पहुंच जो की को दी नहीं गई (मसलन केवल पढ़ने वाली की लिखने की कोशिश कर रही हो), या आपके अकाउंट पर बंद कोई फीचर |
किसी ख़ास वर्कफ़्लो पर 403 का लगभग हमेशा मतलब है कि की उस एप्लिकेशन से अलग किसी एप्लिकेशन की है जिसके पास वह वर्कफ़्लो है। कंसोल में एप्लिकेशन बदलें और इसके बजाय उसकी किसी की का इस्तेमाल करें। पूरी जानकारी: API एरर और उनका मतलब।
#की क्या कर सकती है, यह सीमित करना
की बनाते समय उसकी पहुंच चुनें, और बाद में उसे एक्सेस संपादित करें से बदलें (सीक्रेट वही रहता है; प्राथमिक की की पहुंच संपादित नहीं की जा सकती)। केवल पढ़ने योग्य किसी पार्टनर को कुछ भी बदलने से रोकता है, कस्टम हर रिसोर्स (सेशन, निर्णय, मीडिया, लोग, कंपनियां और भी बहुत कुछ) के लिए कोई नहीं, पढ़ना या लिखना तय करता है, और मीडिया शामिल करें को बंद रखने से कोई सर्विस ID इमेज, सेल्फ़ी, वीडियो और PDF रिपोर्ट डाउनलोड नहीं कर पाती। सीमाएँ के तहत, किसी की को कुछ वर्कफ़्लो तक, सिर्फ़ अप्रूव हुए सेशन तक, या IP पतों की एक लिस्ट तक भी सीमित किया जा सकता है: लिस्ट के बाहर से आई रिक्वेस्ट पर 403 आता है, और की के वर्कफ़्लो या स्टेटस के बाहर के सेशन पर 404 आता है। कोई की ठीक-ठीक क्या कर सकती है, यह देखने के लिए उसे खोलें; कोई की कभी भी अपनी पहुंच से ज़्यादा कुछ नहीं कर सकती।
#आपकी टीम में कौन कीज़ देख सकता है
की दिखना रोल पर निर्भर करता है: पेज देखने के लिए API-कीज़ पढ़ने की परमिशन चाहिए, जो डेवलपर रोल में शामिल है। कंसोल में सीक्रेट छिपे (मास्क) रहते हैं। अगर कोई टीम सदस्य यह पेज नहीं ढूंढ पा रहा, तो रिपोर्ट करने से पहले उसका रोल जांचें। देखें टीम सदस्यों को आमंत्रित करना और रोल तय करना।
#हर कॉल लॉग होती है
API-की से की गई रिक्वेस्ट ऑडिट लॉग में किसी व्यक्ति के बजाय उस की के नाम पर दर्ज होती हैं। यही वजह है कि कई सर्विस में एक ही की शेयर करने से किसी घटना की जांच मुश्किल हो जाती है: हर इस्तेमाल करने वाले के लिए अलग की रखना समझना आसान बनाता है। देखें ऑडिट लॉग का इस्तेमाल।
अभी भी अटके हैं? किसी व्यक्ति से बात करें।
अपने संगठन की ID और जिस सेशन के बारे में पूछ रहे हैं उसकी ID शामिल करें।