Scopes
Çfarë i lejohet të bëjë një çelësi.
Fjalori
Një grup i mbyllur, resource:action. Mjaft i vogël për t'ia treguar një njeriu në një listë me kuti zgjedhjeje, dhe mjaft i qëndrueshëm sa një grantim i ruajtur të ketë të njëjtin kuptim edhe një vit më vonë. I njëjti fjalor është ai me të cilin shkruhet një ROL hapësire pune dhe ai që kontrollon mjetet MCP, prandaj një klient vetëm-lexim nuk mund ta shohë fare një mjet dërgimi. Një alfabet, tri sipërfaqe.
| Scope | Jep |
|---|---|
| emails:send | Dërgon email |
| emails:read | Lexon mesazhet e dërguara dhe statusin e tyre të dorëzimit |
| drafts:read | Lexon skicat |
| drafts:write | Krijon dhe redakton skica |
| threads:read | Lexon bisedat dhe mesazhet |
| threads:write | Etiketon, lexon dhe arkivon biseda |
| labels:read | Lexon etiketat |
| labels:write | Krijon dhe redakton etiketa |
| contacts:read | Lexon kontaktet |
| contacts:write | Shton, redakton dhe heq kontakte |
| audiences:read | Lexon audiencat dhe kush është në to |
| audiences:write | Krijon dhe redakton audienca, dhe ndryshon kush është në to |
| calendar:read | Lexon ngjarjet dhe ftesat e kalendarit |
| calendar:write | Krijon, ndryshon dhe u përgjigjet ngjarjeve të kalendarit |
| templates:read | Lexon shabllonet e email-it dhe i shfaq në paraparje |
| templates:write | Krijon, redakton dhe dërgon me shabllone email-i |
| domains:read | Lexon domenet dhe statusin e tyre DNS |
| domains:write | Verifikon dhe konfiguron domene |
| webhooks:read | Lexon endpoint-et dhe dërgesat e webhook-ëve |
| webhooks:write | Krijon, redakton dhe teston webhook-ë |
| rules:read | Lexon rregullat e postës dhe i teston |
| rules:write | Krijon, redakton dhe rirendit rregullat e postës |
| connections:read | Lexon se cilat kuti postare janë të lidhura |
| members:read | Sheh kush është në hapësirën e punës dhe çfarë mban |
| members:write | Shton dhe heq njerëz, dhe ndryshon çfarë mund të arrijnë |
| roles:read | Lexon rolet që përcakton kjo hapësirë pune |
| roles:write | Krijon, redakton dhe fshin role |
| settings:read | Lexon cilësimet e kutisë postare, përfshirë nënshkrimin |
| settings:write | Ndryshon cilësimet e kutisë postare dhe nënshkrimin |
| keys:write | Zëvendëson sekretin e vet pa hapur askush konsolën |
Një çelës i krijuar pa një listë scope-esh të menduar merr emails:send dhe asgjë tjetër. Parazgjedhja e sigurt për një kredencial është gjëja më e ngushtë që e bën atë të dobishëm.
Një çelës kufizohet nga roli pas tij
Një çelës mund të lëshohet kundrejt një ROLI, dhe një rol është tavan, jo grantim i dytë. Ajo që çelësi mund të bëjë në të vërtetë janë scope-et e tij të NDËRPRERA me lejet e atij roli (key.scopes ∩ role.permissions), të llogaritura një herë te kufiri, në çdo kërkesë, përpara se të arrihet ndonjë endpoint. Asgjë më poshtë nuk e di që ekzistojnë rolet: një scope që roli nuk e mban thjesht nuk është në listën që lexojnë kontrollet e scope-it.
Pra të dyja listat lexohen bashkë dhe asnjëra nuk fiton vetëm. Një çelës që mban emails:send nën një rol që nuk e mban atë nuk mund të dërgojë; një rol që mban emails:send nuk i jep asgjë një çelësi që nuk e kërkoi kurrë. Zgjedhja e një scope-i është kërkesë për autoritet, dhe roli vendos se sa nga ajo që kërkuat merrni.
Një çelës PA rol nuk ka tavan dhe është pra aq i gjerë sa hapësira e punës kundrejt së cilës u lëshua. Kjo është ajo që mbart çdo çelës i krijuar përpara se të ekzistonin rolet dhe ajo që merr ende një owner duke e lënë fushën të paprekur, prandaj një rol null është gjendja më e GJERË në të cilën mund të jetë një çelës, jo më e ngushta. Është edhe arsyeja pse fshirja e një roli ju detyron të thoni ku duhet të shkojnë çelësat e tij: lënia e tyre jetimë do t'i promovonte në heshtje të gjithë.
Ndërprerja zgjidhet për çdo kërkesë, në vend që të vuloset te çelësi në kohën e lëshimit. Kjo e bën ngushtimin e një roli një revokim të drejtpërdrejtë, në fuqi në thirrjen e radhës të thirrësit pa qenë nevoja të rrotullohet çelësi, dhe zgjerimin e tij po aq të drejtpërdrejtë, që është gjysma që ia vlen të mbahet mend.
GET /ping dhe GET /keys/self raportojnë scopes pranë grantedScopes dhe roleId për një dështim të caktuar. scopes është lista efektive dhe e vetmja që autorizon diçka; grantedScopes është ajo me të cilën u lëshua çelësi. Çdo gjë që është te e dyta dhe mungon te e para u mor nga roli, dhe ai dallim është e gjithë përgjigjja për “çelësi im ka emails:send dhe po marr insufficient_scope”. Zgjidhja është një ndryshim roli, jo një çelës tjetër.
curl "$OE/ping" -H "$AUTH" { "ok": true, "keyId": "4c1b257a66287fd113bd89d0", "mode": "live", "scopes": ["emails:read", "threads:read"], "roleId": "role_c40a95f21cc65d31c2a89e07", "grantedScopes": ["emails:send", "emails:read", "threads:read"], "workspaceId": "10417196-e324-4283-af98-66ec62167c47"}Pesë leje nuk mund të arrijnë kurrë te një çelës: api-keys:read, api-keys:write, billing:read, billing:write dhe workspace:manage. Ato janë leje, por jo scope-e, prandaj asnjë rol, sado bujar, nuk mund t'i vërë te një token: krijimi i një çelësi tjetër, ndryshimi i asaj që mund të bëjë një çelës tjetër, ose ndryshimi i planit është diçka që e bën vetëm një person i identifikuar. E vetmja gjë që një çelës mund t'i bëjë vetes është të zëvendësojë sekretin e vet, pas scope-it keys:write. GET /roles/permissions i shënon të pesta me scope: false, gjë që lejon një komponent të vetëm të shfaqë si matricën e roleve ashtu edhe listën me kuti zgjedhjeje për krijimin e çelësave.
roles:write është faktikisht i gjithë fjalori, dhe pretendimi i të kundërtës do të ishte dokumentimi më i rrezikshëm. Një çelës që e mban atë mund t'i bëjë PATCH pikërisht rolit që e kufizon dhe t'i japë vetes gjithçka tjetër, dhe meqë tavani zgjidhet për çdo kërkesë, ai më i gjeri zbatohet që në thirrjen e radhës. Kjo nuk është një vrimë për t'u mbyllur, meqë një redaktues rolesh që nuk mund të redaktojë role nuk është redaktues rolesh. Është një arsye për të mos vënë roles:write te një çelës që vetëm duhej të lexonte listën e anëtarëve.
Scope-i i dërgimit
Veç scope-eve, një çelës mund të ngushtohet edhe në atë që mund të dërgojë si. Ai mbart dy lista. domainAllowlist mban domene të tëra, dhe një çelës që mban një domen mund të dërgojë si çdo adresë e tij, përfshirë adresat e krijuara pas çelësit. addressAllowlist mban adresa të vetme. Lërini të dyja bosh dhe çelësi është aq i gjerë sa hapësira e punës, kurrë më i gjerë. GET /keys/self i tregon të dyja listat dhe GET /addresses raporton se çfarë mund të përdorë në të vërtetë një çelës i dhënë, që është përgjigjja për një from_address_forbidden të pashpjeguar.
I njëjti grup ngushton edhe atë që lexon çelësi. Posta e dërguar, gjurmimi dhe kalendari përgjigjen vetëm për adresat si të cilat çelësi mund të dërgojë, prandaj një çelës i kufizuar në një domen as nuk dërgon dhe as nuk lexon në emër të një tjetri. Një domen i tërë i lejon gjithashtu çelësit të caktojë hostin e gjurmimit të atij domeni, gjë që nuk e bën dot një çelës i kufizuar te adresa të vetme.
Tri ngushtime, pra, dhe ato kombinohen në vend që të mbivendosen: scope-et e çelësit, lejet e rolit mbi të, dhe domenet e adresat që mund të vendosë në një header From. Një dërgim i kërkon të tria, dhe një refuzim emërton vetëm të parin që hasi.