Verschiedene URL der auf Azure-Add-in Call

Question

kann jemand erklären, warum der erste Anruf auf einer Azure-Add-in mit OpenIdConnectAuthentication von Sharepoint Online hat die Url:

https://login.microsoftonline.com/tenantGuid/oauth2/authorize?client_id=xxx&response_mode=form_post&response_type=code+id_token&scope=openid+profile&state=OpenIdConnect.AuthenticationProperties%... 

und der zweite Aufruf hat die URL

https://yyy.sharepoint.com/_layouts/15/online/cloudappsredirect.aspx?addintype=FileHandler&usemds=false&appurl=https%...&params 

Gibt es eine Möglichkeit, die Parameter von Url2 auch vom ersten Aufruf zu erhalten?

EDIT

Haben Sie einen Tipp von einem Kumpel und aus dem GPX file handler Code.

In den Benachrichtigungen der OpenIdConnectAuthenticationOptions können Sie die RedirectToIdentityProvider Func angeben. Hier können Sie alle notwendigen Informationen des Query-Strings in einem Cookie speichern, da Session hier nicht funktioniert.

RedirectToIdentityProvider = (context) => 
{ 
    var directoryAndFilenameReferrer = System.Web.HttpContext.Current.Request.UrlReferrer.Query.Split('&').Where(x => x.StartsWith("itemurl", StringComparison.Ordinal)).FirstOrDefault(); 
    var directoryAndFilename = System.Web.HttpUtility.UrlDecode(directoryAndFilenameReferrer).Split('/'); 
    context.Response.Cookies.Append("cookie_Filename", directoryAndFilename[directoryAndFilename.Length - 1]); 
    return Task.FromResult(0); 
} 

Vergessen Sie nicht, den Cookie danach zu löschen.

Answer 1

Die kurze Antwort ist: Nein, das sind zwei verschiedene Dienste, die verschiedenen Zwecken dienen, basierend auf verschiedenen Informationen.

Dies scheint eine Dateihandler-App zu sein. Wie jede andere App ist es "extern" zu den Microsoft-Cloud-Workloads (SharePoint, Exchange usw.). Daher muss es einige Beweise (Token) bereitstellen, dass es mit dem gewünschten Workload (SharePoint/OneDrive in diesem Fall) arbeiten darf .)

Der erste Aufruf ist der einzige Autorisierungsdienst in der Microsoft Business Cloud - um die Anmeldeinformationen der App (und des Benutzers) zu überprüfen. Das Ergebnis ist ein Autorisierungs-Token. Dieser Dienst kennt keine Laufwerke und Dateien.

Der zweite Aufruf ist Datei-spezifisch - Ihre App muss die URLs GET und PUT der Datei ermitteln, die sie verarbeiten wird. Diese Informationen werden nur in SharePoint/OneDrive gespeichert. Deshalb ist dieser Aufruf zu SharePoint/OneDrive unvermeidbar. Wie oben erwähnt, benötigt dieser Anruf ein Autorisierungstoken, das durch den ersten Anruf erworben wird.

Wenn Ihre Frage ist, warum SharePoint keine eigenen Autorisierungs-Token produziert, ist das ein Thema für eine längere Diskussion. Kurz gesagt, ein separater Autorisierungsdienst ermöglicht Apps den Zugriff auf mehrere Workloads mit einer einzigen Benutzerauthentifizierung und Zustimmung und ist weniger fehleranfällig. Sie können hier über OAuth 2.0 nachlesen - http://oauth.net/2/.