Ç'mund të arrijë
Kufiri i ndershëm.
Roli juaj vendos cilat vegla ekzistojnë
Serveri vepron si ju, kundrejt lidhjes që keni bërë aktive. Nuk ka llogari shërbimi të veçantë dhe as qasje më të gjerë se e juaja. Që kur dolën rolet, nuk ka as qasje më të gjerë se ROLI juaj. Lista e veglave që i jepet një klienti ndërtohet nga lejet që mbani në hapësirën aktive të punës, kështu që klienti i një shikuesi nuk i rendit fare sendEmail, createRule ose sendWithTemplate.
Kjo është gjë më e fortë sesa refuzimi i thirrjes. Një vegël që mungon nga lista nuk është vegël për të cilën arsyeton modeli, nuk ha kontekst dhe nuk mund të provohet në emër të dikujt e pastaj të kërkohet falje për të. Do të thotë gjithashtu se një klient që duket bosh zakonisht është një leje që nuk e mbani e jo një veçori që i mungon këtij serveri, gjë që është pikërisht ajo për të cilën ekziston whoAmI t'jua thotë.
Regjistrimi dhe thirrja janë dy porta, dhe vetëm e dyta mban. Lista ndërtohet një herë, kur hapet sesioni, dhe setActiveConnection mund ta zhvendosë atë sesion në një kuti postare ku mund të bëni më pak, kështu që lista është e vjetruar nga vetë ndërtimi dhe protokolli nuk ka mënyrë ta tërheqë një vegël në mes të sesionit. Prandaj çdo vegël e kontrolluar e rizgjidh rolin tuaj kundrejt lidhjes AKTUALE para se të ekzekutohet. Regjistrimi është mirësjellja; thirrja është kufiri.
Një refuzim emërton të dyja gjysmat, si te Refused (missing_permission): your role in this mailbox is Viewer, which does not include “Send email”, që një agjent të mund t'ia shpjegojë personit për të cilin punon dhe të ndalojë së provuari, në vend që të riprovojë një gabim të errët derisa dikush të dorëzohet. Një rol i ndryshuar nga një admin ndërsa sesioni është i hapur bie njësoj, në thirrjen e parë që vjen.
Adresat janë boshti tjetër dhe nuk preken nga asgjë prej kësaj. Një rol thotë çfarë mund të bëni; adresat që ju janë dhënë thonë në cilat kuti postare mund ta bëni, dhe të dyja duhet të pajtohen para se të dalë një mesazh.
Vetë token-i është ende pa scope
Ajo që NUK ka ndryshuar është granti. Token-i që merr një aplikacion arrin gjithçka që lejon roli juaj, e jo një nënbashkësi që zgjodhët gjatë miratimit, kështu që miratimi i një klienti është miratimi i tij për gjithçka që mund të bëni në atë hapësirë pune. Ju tregohet kush po kërkon para se të jepet çfarëdo gjëje, dhe Llogaria → Aplikacionet e lidhura e heq më pas, duke fshirë çdo token që mban dhe miratimin pas tij, por zgjedhja “vetëm lexim, për këtë aplikacion” nuk është ndërtuar.
Pra tavani i një klienti MCP është tavani JUAJ. Ngushtimi i asaj që mund të bëjë një aplikacion do të thotë ngushtim i rolit të personit që e lidhi, gjë që ngushton edhe atë që mund të bëjë ai vetë në aplikacion. Kjo është forma e ndershme e saj sot, dhe arsyeja pse një scope për çdo grant vlen ende të ndërtohet.
Fjalori është tashmë i përbashkët: lejet e një roli dhe scope-et e një çelësi API janë marrë nga një alfabet i vetëm, gjë që e bën autoritetin e një çelësi të llogaritshëm si prerje e të dyjave. Një scope MCP për çdo grant do të shprehet me të njëjtat fjalë kur të mbërrijë.