Ich arbeite mit MSAL und habe einen Benutzer, der den folgenden Fehler erhalten hat:
%Vor%Der Code ist der standardmäßige MSAL-Democode:
%Vor%Es stellt sich heraus, dass die Integration so ist:
Frage
Wie sollte ich für die obige Situation defensiv codieren? (oder ähnliche hybride Situationen)?
Alte Frage, aber es scheint, dass andere darin gelandet sind.
Dies ist nicht wirklich ein MSAL-Problem, da das Token selbst hier nicht das Problem ist. Die Ausnahme stammt vom Aufruf von https://graph.microsoft.com/v1.0/me/messages , wenn der Benutzer kein zugängliches Postfach hat.
Sie können im Allgemeinen feststellen, welche Ressourcen einem user zugewiesen wurden, indem Sie sich die provisionedPlans Sammlung:
Dadurch werden Sammlungsressourcen zurückgegeben, die für den Benutzer bereitgestellt wurden. Dieser Benutzer hat beispielsweise keine Exchange-Bereitstellung:
%Vor%Vergleichen Sie dies mit diesem Benutzer, für den ExCange bereitgestellt wurde:
%Vor% Eine ähnliche Eigenschaft, die auch nützlich sein kann, ist assignedPlans Dadurch werden die Ressourcen zurückgegeben, die user zugewiesen wurden. Dies ist nützlich, um festzustellen, ob die Bereitstellung noch nicht erfolgt ist, oder um Ressourcen zu ermitteln, die nicht formell "bereitgestellt" werden, z. B. Microsoft Teams.
Das heißt, Sie sollten immer defensiv für die Möglichkeit kodieren, dass ein Benutzer keine Berechtigung für eine angeforderte Ressource hat oder nicht hat. Es gibt mehrere Szenarien, in denen eine Ressource aufgrund eines Ausfalls oder von Benutzerberechtigungen möglicherweise nicht verfügbar ist und die einzige sichere Methode zur Behebung dieser Szenarien darin besteht, mit einer soliden Ausnahmebehandlung zu stoppen.
Tags und Links c# office365 microsoft-graph msal