दस्तावेज़ पर जाएँ
API

प्रमाणीकरण

एक ही प्रकार का क्रेडेंशियल, और वे तरीके जिनसे कोई अनुरोध अस्वीकार होता है।

जाँचें कि कुंजी काम करती है

GET /ping धुआँ-परीक्षण है: इसे किसी scope की ज़रूरत नहीं और यह बताता है कि कुंजी क्या है।

curl
curl "$OE/ping" -H "$AUTH"
प्रतिक्रिया
{  "ok": true,  "keyId": "4c1b257a66287fd113bd89d0",  "mode": "live",  "scopes": ["emails:send", "emails:read"],  "roleId": null,  "grantedScopes": ["emails:send", "emails:read"],  "workspaceId": "10417196-e324-4283-af98-66ec62167c47"}

अगर यह काम करता है और कुछ और 401 देता है, तो समस्या scope की है, कुंजी की नहीं।

scopes प्रभावी सूची है और केवल वही किसी चीज़ को अधिकृत करती है। grantedScopes वह है जिसके साथ कुंजी जारी हुई थी, और दोनों में अंतर तभी होता है जब कोई भूमिका कुंजी पर सीमा लगा रही हो। Scopes पृष्ठ उस प्रतिच्छेदन को समझाता है। roleId का null होना मतलब कोई ऊपरी सीमा नहीं, जो किसी कुंजी की सबसे विस्तृत स्थिति है।

देखें कि कुंजी किसके रूप में भेज सकती है

GET /addresses उस 403 का उत्तर है जिसकी आपने अपेक्षा नहीं की थी।

curl
curl "$OE/addresses" -H "$AUTH"
प्रतिक्रिया
{  "object": "list",  "unrestricted": false,  "data": [    { "object": "address", "address": "[email protected]", "enabled": true, "canSend": true },    { "object": "address", "address": "[email protected]", "enabled": true, "canSend": false }  ],  "domains": [    { "domain": "acme.com", "receivingVerified": true, "sendingVerified": true, "catchAll": false }  ]}

canSend: false के तीन कारण होते हैं: पता बंद है, कुंजी का send scope उसे शामिल नहीं करता (न उसका डोमेन, न स्वयं पता कुंजी पर है), या डोमेन अभी हस्ताक्षर नहीं कर सकता। पते पर enabled और उसके डोमेन पर sendingVerified इनमें फ़र्क बताते हैं, और यही वह चीज़ है जिससे यह एंडपॉइंट डीबगिंग का सबसे ज़्यादा समय बचाता है। कोई डोमेन प्राप्ति के लिए सत्यापित हो सकता है और फिर भी भेज न पाए।

unrestricted: true का अर्थ है कि किसी भी सत्यापित डोमेन पर कोई भी local-part स्वीकार है, वे भी जो अभी किसी ने बनाए ही नहीं।

कुंजी कैसे अस्वीकार होती है

कोडअर्थ
missing_api_keyकोई Authorization हेडर है ही नहीं।
invalid_credential_typeकोई कुकी या सेशन टोकन। API कुंजी भेजें।
invalid_api_keyयह हमारी जारी की हुई कुंजी नहीं है, या गुप्त मान मेल नहीं खाता।
revoked_api_keyयहीं जारी हुई, फिर रद्द कर दी गई। यह अंतर जानबूझकर रखा गया है। यही पाँच मिनट की मरम्मत और पूरी दोपहर के बीच का फ़र्क है।
expired_api_keyयहीं जारी हुई, फिर समाप्त हो गई।
insufficient_scopeअसली कुंजी, पर उस scope के बिना जो यह एंडपॉइंट माँगता है।

रद्द करना अगली कॉल से प्रभावी होता है। पंक्ति उसके बाद भी keys पृष्ठ पर बनी रहती है, ताकि आप देख सकें कि जब आपने कुंजी बंद की तब कुछ उसका इस्तेमाल कर रहा था या नहीं। उस स्क्रीन पर सबसे उपयोगी स्थिति "कभी इस्तेमाल नहीं हुई" है, क्योंकि इसी से लीक हुई कुंजी और जीवित निर्भरता में फ़र्क पता चलता है।

किसी गुप्त मान को सेवानिवृत्त करने का दूसरा तरीका रोटेशन है। यह उसी कुंजी के लिए नया गुप्त मान गढ़ता है, इसलिए id, नाम, scopes, भूमिका, send scope और हर request तथा activity पंक्ति चलती रहती है; केवल गुप्त मान बदलता है। पुराना मान रोटेशन पूरा होते ही काम करना बंद कर देता है, बिना किसी ओवरलैप विंडो के, और नया मान एक ही बार दिखाया जाता है। कंसोल में यह Revoke के साथ उसी मेन्यू में है और पहले दोबारा सत्यापन माँगता है। keys:write रखने वाली कुंजी POST /keys/self/rotate से ख़ुद को भी रोटेट कर सकती है, जिससे कोई इंटीग्रेशन बिना किसी के कंसोल खोले, तय समय पर रोटेट होता है।