Microsoft je uveo funkcionalnost u dodijelite sponzore korisnicima Entra ID Guest natrag u 2023. Na pozadini je to moguće putem sponzori odnos/navigacijsko svojstvo za korisnički resurs i njegove pridružene metode. Iskorištavanjem navedenog svojstva može se izraditi izvješće koje navodi sponzor(e) za svakog gostujućeg korisnika, kao što je ovaj. Loša strana ovoga je nedostatak podrške za pravilno filtriranje, što se prevodi u potrebu dohvaćanja svih objekata i provjere njihovih sponzori vlasništvo. Nije idealno. Stvari postaju još kompliciranije ako želite prijaviti skup objekata za koje je bilo koji korisnik sponzor.
Pa, sada se Microsoft bavi time uvođenjem sponzorOf odnos za korisničke objekte i njima pridružene POPIS sponzorOf metoda. Još jedan niz nedavnih poboljšanja dao nam je mogućnost dodjele sponzora skupu objekata direktorija povezanih s umjetnom inteligencijom: nacrtima agenata, principalima nacrta agenata, identitetima agenata i korisnicima agenata. Drugim riječima, sponzor koncept više nije ograničen na korisnike goste, što čini dodatak sponzorOf još utjecajniji.
The sponzorOf zbirka nije uključena u zadani izlaz za korisnički objekt, tako da ćete je morati posebno zatražiti putem $proširi operater. Alternativno, koristite /users/{userId}/sponsorOf put. Osim toga, u vrijeme pisanja ovog članka nekretnina je izložena samo pod /beta Graph 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 morate biti svjesni je da je svojstvo trenutačno izloženo samo putem dopuštenja delegata. Ili barem tako kaže službena dokumentacija. Zapravo, možete dobiti odgovor na a /sponzorOf upit putem dopuštenja aplikacije sasvim je u redu, barem to otkrivaju moji testovi. No budući da o tome ne mogu govoriti u ime Microsofta, pretpostavimo da postoje valjani razlozi za ovaj zahtjev.
Još jedna stvar koju treba imati na umu je sama dozvola. Dok Korisnik.Pročitaj.Sve dovoljan je za pokrivanje pojedinosti za sve korisničke objekte, ne uzima u obzir scenarije povezane s agentima. Dok bi Graph API trebao dotjerati odgovori u takvim scenarijima, za /sponzorOf upita umjesto toga biste mogli završiti s oštećenim JSON izlazom. Evo jednog primjera koji sam dobio u 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 gornja poruka o pogrešci na površini ne čini povezanom s dopuštenjima, nestaje kada se zahtjev ponovno pokrene s prilagođenim (širim) dopuštenjima. Stoga, da biste osigurali odgovarajuće iskustvo, morat ćete ili iskoristiti kombinaciju Korisnik/AgentIdentity/AgentIdentityBlueprint.Read.All dopuštenja ili jednostavno idite s širokim Imenik.Pročitaj.Sve jedan.
Naravno, stvari postaju malo zanimljivije kada se želimo okupiti sponzorOf podatke za sve naše korisnike. Ovo je mjesto gdje se koristi $filter i $odaberi operateri mogu uvelike poboljšati iskustvo jer mogu smanjiti količinu vraćenih podataka. Ipak, najvažniji scenarij, naime mogućnost filtriranja (ili samo dohvaćanja) korisnika bez ikakvih sponzoriranih objekata, ne može se riješiti na strani poslužitelja. 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 za daljnje smanjenje veličine izlaza. Imajte na umu da filtri koji uključuju sponzorOf čini se da funkcionira samo kao dio napredni upiti trenutno, pa svakako dodajte ConsistentLevel=eventual zaglavlje i $count=true operater. Ispod je nekoliko primjera koji bi mogli biti od koristi:
#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, kao što se mora koristiti $proširi kako bismo uključili sponzorirane objekte u izlaz bilo kojeg LIST upita (skupno dohvaćanje korisnika), podliježemo ograničenjima navedenog operatora. Naime, ne možemo ga kombinirati s (naprednim) upitima za filtriranje i izlaz je ograničen na 20 objekata, tako da možete dobiti nepotpuni skup sponzoriranih objekata. To pak znači da ako želimo ispravan inventar za cijelog stanara, moramo to učiniti po korisniku. Ali ako samo želite dobiti naznaku o tome je li korisnički objekt trenutno dodijeljen kao sponzor bilo čemu, zadnji primjer iznad trebao bi dobro poslužiti.
GET https://graph.microsoft.com/beta/users?$expand=sponsorOf($select=id)&$select=id
Još jedna stvar prije nego što zatvorimo članak. Možda se sjećate da su neki Graphovi odnosi tranzitivni po prirodi, to jest mogu biti “ugniježđeni”. Budući da sponzorski odnosi također podržavaju gniježđenje, dodjeljivanjem grupe kao sponzora određenog objekta, moramo se pobrinuti i za takve scenarije. Microsoft je dizajnirao sponzorOf svojstvo da uvijek vraća i izravno i neizravno sponzorirane objekte, tako da zapravo uvijek dobivamo tranzitivni skup. Ili barem tako stoji u dokumentaciji.
U mojim testovima u izlazu nisu vraćeni unosi dodijeljeni grupi sponzorOf. No, brza provjera otkrila je postojanje (nedokumentiranog) sponzorOf odnos za grupne objekte, dostupan pod /groups/{groupid}/sponsorOf krajnja točka:
GET https://graph.microsoft.com/beta/groups/37e85861-5e4e-4670-9dfd-07e22a678779/sponsorOf
S druge strane, čini se da trenutačno ne postoji podrška za korištenje navedene imovine putem $proširi operator u grupnim upitima. Pretpostavljam da je to dio razloga sponzorOf je još uvijek dostupan samo u beta verziji, a stvari bi mogle početi funkcionirati kako je oglašeno nakon što se potrebne promjene koda uvedu u cijeloj usluzi.
A to je ukratko kako raditi s nedavno predstavljenim sponzorOf svojstvo u Graph API-ju. Mali, smisleni dodatak skupu svojstava/odnosa izloženih na korisničkom resursu, što nekoliko scenarija čini jednostavnijim za implementaciju. Nadamo se da se stvari mogu dodatno poboljšati boljom podrškom za filtriranje, ali takva se izjava može proširiti na Graph u cjelini… to je što jest. Kao posljednja napomena, budući da je sve ovo još uvijek dio beta/preview izdanja, stvari bi se mogle promijeniti do trenutka kada pročitate ovaj članak.