Kimlik doğrulama
Tek bir kimlik bilgisi türü ve bir isteğin reddedilme biçimleri.
Başlık
Temel URL localhost:2222 adresidir. Her istek anahtarı bir Authorization başlığında taşır.
Authorization: Bearer oe_live_9f2c1a4b7e05d3862c1f0a44_kX7…Burada başka hiçbir şey kimlik doğrulamaz. Oturum çerezi de oturum belirteci de invalid_credential_type ile reddedilir; bu kod, çıplak bir 401 karşısında tahmin yürütmenize bırakmak yerine bunun yerine gönderilmesi gereken kimlik bilgisini adlandırır.
Anahtarın çalıştığını doğrulama
GET /ping duman testidir: hiçbir kapsam gerektirmez ve anahtarın ne olduğunu size söyler.
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"}Bu çalışıyor ve başka bir şey 401 veriyorsa sorun anahtar değil kapsamdır.
scopes ETKİN listedir ve herhangi bir şeye yetki veren tek listedir. grantedScopes anahtarın verilirken aldığı listedir; ikisi yalnızca bir rol anahtarı sınırladığında farklılaşır. Bu kesişimi Kapsamlar sayfası açıklar. roleId değerinin null olması tavan olmadığı anlamına gelir; bu da bir anahtarın erişebileceği en geniş durumdur.
Bir anahtarın hangi adreslerle gönderebileceğini görme
GET /addresses, beklemediğiniz bir 403'ün yanıtıdır.
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 durumunun üç nedeni vardır: adres kapalıdır, anahtarın gönderim kapsamı onu dışarıda bırakır (ne alan adı ne de adresin kendisi anahtarda vardır) ya da alan adı henüz imzalayamaz. Adresteki enabled ile alan adındaki sendingVerified bunları birbirinden ayırır ve bu uç noktanın kazandırdığı hata ayıklama süresinin çoğu buradadır. Bir alan adı posta almak için doğrulanmışken yine de gönderim yapamıyor olabilir.
unrestricted: true, doğrulanmış bir alan adındaki herhangi bir local-part'ın kabul edildiği anlamına gelir; henüz kimsenin oluşturmadıkları da dahil.
Bir anahtar nasıl reddedilir
| Kod | Anlamı |
|---|---|
| missing_api_key | Hiç Authorization başlığı yok. |
| invalid_credential_type | Bir çerez ya da oturum belirteci. Bir API anahtarı gönderin. |
| invalid_api_key | Bizim verdiğimiz bir anahtar değil ya da gizli değer eşleşmiyor. |
| revoked_api_key | Burada verilmiş, sonra iptal edilmiş. Ayrı tutulması bilinçlidir. Beş dakikalık bir düzeltmeyle bir öğleden sonranın farkı budur. |
| expired_api_key | Burada verilmiş, sonra süresi dolmuş. |
| insufficient_scope | Gerçek bir anahtar, ama bu uç noktanın gerektirdiği kapsam onda yok. |
İptal, bir sonraki çağrıda geçerli olur. Satır sonrasında da anahtarlar sayfasında kalır; böylece anahtarı öldürdüğünüzde onu kullanan bir şey olup olmadığını hâlâ görebilirsiniz. O ekrandaki en işe yarar durum "hiç kullanılmadı" durumudur, çünkü sızmış bir anahtarı canlı bir bağımlılıktan ayırmanın yolu budur.
Bir gizli değeri emekliye ayırmanın öteki yolu rotasyondur. Aynı anahtar için yeni bir gizli değer üretir; böylece id, ad, kapsamlar, rol, gönderim kapsamı ve bütün istek ile etkinlik satırları olduğu gibi kalır, yalnızca gizli değer değişir. Eskisi rotasyon tamamlandığı anda çalışmayı bırakır, örtüşme penceresi yoktur ve yenisi bir kez gösterilir. Konsolda Revoke ile aynı menüdedir ve önce yeniden doğrulama yapmanızı ister. keys:write taşıyan bir anahtar POST /keys/self/rotate ile kendi rotasyonunu da yapabilir; bir entegrasyonun kimse konsolu açmadan düzenli aralıklarla rotasyon yapması böyle sağlanır.