Hitelesítés
Egyetlen hitelesítőadat-típus, és azok a módok, ahogyan egy kérést elutasít.
A fejléc
Az alap-URL az api.openemail.uk. Minden kérés egy Authorization fejlécben viszi a kulcsot.
Authorization: Bearer oe_live_9f2c1a4b7e05d3862c1f0a44_kX7…Semmi más nem hitelesít itt. A munkamenet-sütit és a munkamenet-tokent is invalid_credential_type hibával utasítja el, amely megnevezi a helyette küldendő hitelesítőadatot, ahelyett hogy egy puszta 401 mellett találgatnod kellene.
Kulcs működésének ellenőrzése
A GET /ping a füstpróba: nem igényel hatókört, és megmondja, mi az a kulcs.
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"}Ha ez működik, de valami más 401-et ad, akkor a hatókörrel van baj, nem a kulccsal.
A scopes a TÉNYLEGES lista, és egyedül az jogosít fel bármire. A grantedScopes az, amivel a kulcsot kiadták, és a kettő csak akkor tér el, ha egy szerepkör korlátozza a kulcsot. A Hatókörök oldal elmagyarázza ezt a metszetet. A null értékű roleId azt jelenti, hogy nincs felső korlát, és ez a legtágabb állapot, amit egy kulcs elérhet.
Mit küldhet egy kulcs feladóként
A GET /addresses a válasz arra a 403-ra, amelyre nem számítottál.
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 } ]}A canSend: false értéknek három oka lehet: a cím ki van kapcsolva, a kulcs küldési hatóköre kihagyja (sem a domainje, sem maga a cím nincs rajta a kulcson), vagy a domain még nem tud aláírni. A cím enabled mezője és a domain sendingVerified mezője különbözteti meg ezeket, és ez az, amivel ez a végpont a hibakeresési idő nagy részét megspórolja. Egy domain lehet fogadásra hitelesítve úgy is, hogy küldeni még nem tud.
Az unrestricted: true azt jelenti, hogy egy hitelesített domainen bármilyen local-part elfogadott, azok is, amelyeket még senki nem hozott létre.
Hogyan utasít el egy kulcsot
| Kód | Jelentése |
|---|---|
| missing_api_key | Egyáltalán nincs Authorization fejléc. |
| invalid_credential_type | Süti vagy munkamenet-token. Küldj API kulcsot. |
| invalid_api_key | Nem általunk kiadott kulcs, vagy nem egyezik a titok. |
| revoked_api_key | Itt adtuk ki, aztán visszavonták. Szándékosan külön kód. Ez a különbség egy ötperces javítás és egy egész délután között. |
| expired_api_key | Itt adtuk ki, aztán lejárt. |
| insufficient_scope | Valódi kulcs, a végpont által igényelt hatókör nélkül. |
A visszavonás a következő hívástól érvényes. A sor utána is a kulcsok oldalán marad, így továbbra is megállapítható, használta-e valami a kulcsot, amikor kilőtted. A legtöbbet mondó állapot azon a képernyőn a „soha nem használt”, mert így lehet megkülönböztetni egy kiszivárgott kulcsot egy élő függőségtől.
A rotálás a másik módja egy titok nyugdíjazásának. Új titkot állít elő ugyanahhoz a kulcshoz, így az azonosító, a név, a hatókörök, a szerepkör, a küldési hatókör és minden kérés- és tevékenységsor megmarad; csak a titok változik. A régi abban a pillanatban érvénytelen lesz, amint a rotálás befejeződik, átfedési ablak nélkül, a cserét pedig egyszer mutatjuk meg. A konzolon ugyanabban a menüben van, mint a Visszavonás, és előbb újbóli azonosítást kér. A keys:write hatókörrel rendelkező kulcs önmagát is rotálhatja a POST /keys/self/rotate hívással, így egy integráció ütemezetten rotálhat anélkül, hogy bárki megnyitná a konzolt.