Microsoft je još 2023. godine uveo funkciju dodjele sponzora korisnicima Entra ID Guesta. Na pozadinskoj strani, to je moguće putem sponzori svojstvo odnosa/navigacije za korisnički resurs i njegove pridružene metode. Iskorištavanjem navedenog svojstva može se kreirati izvještaj koji navodi sponzore za svakog gosta korisnika, kao što je ovaj. Nedostatak ovoga je nedostatak podrške za pravilno filtriranje, što se prevodi u potrebu da se dohvate svi objekti i oni validiraju sponzori imovine. Nije idealno. Stvari postaju još složenije ako želite prijaviti skup objekata čiji je bilo koji korisnik sponzor.
Pa, sada se Microsoft bavi tim uvođenjem sponzorOf odnos za korisničke objekte i one povezane s njima LIST SponsorOf metoda. Drugi skup nedavnih poboljšanja nam je dao mogućnost da dodijelimo sponzore skupu objekata direktorija povezanih s umjetnom inteligencijom: nacrti agenata, principali nacrta agenata, identiteti agenata i korisnici agenata. drugim riječima, sponzor koncept više nije ograničen na gostujuće korisnike, što čini dodatak sponzorOf još uticajniji.
The sponzorOf kolekcija nije uključena u zadani izlaz za korisnički objekt, tako da ćete je morati zasebno zatražiti putem $expand operater. Alternativno, koristite /users/{userId}/sponsorOf vrijeme. Osim toga, u vrijeme pisanja imovina je izložena samo pod /beta Graf API grana. Evo nekoliko primjera:
#List all objects the current user is a member of GET https://graph.microsoft.com/beta/me/sponsorOf GET https://graph.microsoft.com/beta/me?$expand=sponsorOf #List all objects a given user is a member of GET https://graph.microsoft.com/beta/users/user@domain.com/sponsorOf GET https://graph.microsoft.com/beta/users/user@domain.com?$expand=sponsorOf
Osim što je dostupan samo u /betajoš jedno ograničenje kojeg treba imati na umu je da je svojstvo trenutno izloženo samo putem ovlaštenja delegata. Ili bar tako kaže zvanična dokumentacija. U stvari, možete dobiti odgovor na a /sponsorOf traženje dozvola putem aplikacije je sasvim u redu, barem to otkrivaju moji testovi. Ali pošto ne mogu govoriti u ime Microsofta o ovome, pretpostavimo da postoje valjani razlozi za ovaj zahtjev.
Još jedna stvar koju treba imati na umu je sama licenca. Dok User.Read.All dovoljno je da pokrije detalje za sve korisničke objekte, ne uzima u obzir scenarije vezane za agente. Dok bi Graph API trebao fino podesiti odgovore u takvim scenarijima, for /sponsorOf upita, umjesto toga možete završiti s iskrivljenim JSON izlazom. Evo primjera koji sam dobio na svojim testovima:
{"error":{"code":"InternalServerError","message":"The property 'signInAudienceRestrictions[Nullable=False]' of type 'microsoft.graph.signInAudienceRestrictionsBase' h
as a null value, which is not allowed.","innerError":{"date":"2026-07-29T08:27:29","request-id":"7ae3a73a-a205-4902-9c8d-0c113d5798dc","client-request-id":"7ae3a73a-a205-4902-9c8d-0c113d5798dc"}}Iako se čini da gornja poruka o grešci na površini nije povezana s dozvolama, ona nestaje kada se zahtjev ponovo pokrene s prilagođenim (širim) dozvolama. Stoga, da biste osigurali odgovarajuće iskustvo, morat ćete koristiti kombinaciju User/AgentIdentity/AgentIdentityBlueprint.Read.All dozvole ili jednostavno idite sa širokim Directory.Read.All jedan.
Naravno, stvari postaju malo zanimljivije kada želimo da se nađemo sponzorOf podatke za sve naše korisnike. Ovdje se koristi $filter i $odaberi operateri mogu uvelike poboljšati iskustvo jer mogu smanjiti količinu vraćenih podataka. Međutim, najvažniji scenario, odnosno mogućnost filtriranja (ili samo preuzimanja) korisnika bez ikakvih sponzoriranih objekata, ne može se upravljati na strani servera. Drugim riječima, a $filter=sponsorOf/$count eq 0 trenutno nije podržano.
Međutim, još uvijek možete filtrirati sponzorOf izlaz kao i ograničavanje skupa vraćenih svojstava kako bi se dodatno smanjila veličina izlaza. Imajte na umu da filteri koji uključuju sponzorOf Čini se da trenutno radi samo kao dio naprednih upita, pa ga svakako dodajte ConsistentLevel=eventual zaglavlje i $count=true operater. U nastavku su neki primjeri koji mogu biti korisni:
#Fetch all users along with their sponsored objects GET https://graph.microsoft.com/beta/users?$expand=sponsorOf #Fetch all non-user objects the current user is a sponsor of (advanced query!) GET https://graph.microsoft.com/beta/me/sponsorOf?$filter=userType ne 'Guest'&$count=true #Fetch just the id of all users along with the id of their sponsored objects GET https://graph.microsoft.com/beta/users?$expand=sponsorOf($select=id)&$count=true&$select=id
Nažalost, jer se mora koristiti $expand da bismo uključili sponzorirane objekte u izlaz bilo kojeg LIST upita (skupno preuzimanje korisnika), podliježemo ograničenjima navedenog operatora. Naime, ne možemo ga kombinirati sa (naprednim) upitima za filtriranje i izlaz je ograničen na 20 objekata, tako da možete dobiti nepotpun skup sponzoriranih objekata. To znači da ako želimo ispravan inventar za cijelog zakupca, to moramo učiniti po korisniku. Ali ako samo želite dobiti indikaciju da li je korisnički objekt trenutno dodijeljen kao sponzor nečemu, posljednji primjer iznad bi trebao biti sasvim u redu.
GET https://graph.microsoft.com/beta/users?$expand=sponsorOf($select=id)&$select=id
Još nešto prije nego što zatvorimo članak. Možda se sjećate da su neke Graph relacije tranzitivne prirode, odnosno da se mogu “ugnijezditi”. Budući da odnosi sponzora također podržavaju ugniježđenje, dodjeljivanjem grupe kao sponzora određenog objekta, moramo voditi računa i o takvim scenarijima. Dizajnirao je Microsoft sponzorOf svojstvo da uvijek vraća i direktno i indirektno sponzorirane objekte, tako da zapravo uvijek dobijemo tranzitivni skup. Ili bar tako piše u dokumentaciji.
U mojim testovima, unosi dodijeljeni grupi nisu vraćeni u izlaz sponzorOf. Ali brza provjera otkrila je postojanje (nedokumentovanog) sponzorOf odnos za grupne objekte, dostupan pod /groups/{groupid}/sponsorOf krajnja tačka:
GET https://graph.microsoft.com/beta/groups/37e85861-5e4e-4670-9dfd-07e22a678779/sponsorOf
S druge strane, čini se da trenutno ne postoji podrška za korištenje navedene imovine putem $expand operator u grupnim upitima. Pretpostavljam da je to dio razloga sponzorOf još uvijek je dostupan samo u beta verziji, a stvari mogu početi raditi kako je objavljeno kada se neophodne promjene koda uvedu u servis.
A to je ukratko kako raditi sa nedavno predstavljenim sponzorOf svojstvo u Graph API-ju. Mali, smisleni dodatak skupu svojstava/relacija izloženih na korisničkom resursu, čineći nekoliko scenarija jednostavnijim za implementaciju. Nadamo se da se stvari mogu dodatno poboljšati sa boljom podrškom za filtriranje, ali takva izjava se može proširiti na Graph kao cjelinu… to je ono što jeste. Kao konačna napomena, budući da je sve ovo još uvijek dio beta/preview izdanja, stvari su se možda promijenile do trenutka kada pročitate ovaj članak.