2017-12-19 5 views
0

Ich benutze asp.net Core 2.0 mit IdentityServer 4 und Angular 5.0.autorisieren Callback/redirect_url Routen zu clientside Route führt zu Rekursion Anrufe

Mein Projekt ist auf dieser Probe basiert:

https://github.com/scottbrady91/Angular4-OidcClientJs-Example

Wenn der Benutzer in erfolgreich angemeldet ist er auf den bestimmten autorisierten Rückruf umgeleitet wird.

In Scott Brady`s Probe, dass client Route genannt wird:

{ 
    path: 'auth-callback', 
    component: AuthCallbackComponent, 
    }, 

Bisher funktioniert alles.

ABER ... meine echte Anwendung hat NUR geschützte Routen.

Also änderte es die obige Probe:

{ 
     path: 'auth-callback', 
     component: AuthCallbackComponent, 
     **canActivate: [AuthGuardService]** 
     }, 

jetzt bekomme ich eine Rekursion Umleitung von Serverside authorise Endpunkt des Auth-Rückruf und zurück zum server authorise Endpunkt.

kann ich nicht einmal im Browser debuggen, weil alles schnell springt um mit den Quelldateien ...

  1. Was ist die Auth-Rückruf ROUTE aussehen soll? Muss es ungeschützt sein? Wie gesagt, ich habe nur Routen geschützt.
  2. Was muss ich in Scott Brady`s Sample beheben, dass die Rekursion aufhört?

Ich fand heraus, dass der Benutzer Feld in der auth.aervice.ts nach der auth.guard.ts.isLoggedIn() Funktion null ausgelöst wird, aber ich weiß nicht, warum der Anruf für den Benutzer null zurück . Dieses Null-Benutzer-Problem ist nur mit dem Auth-Callback vorher nicht.

Antwort

0

Ich habe noch nie mit einem Javascript-Client gearbeitet, daher kann ich Ihnen bei der Konfiguration nicht helfen. Aber ich denke, ich kann Ihnen helfen, das zu lösen.

Wie Sie vermutet haben, ist das Problem, dass alle Ihre Routen geschützt sind. Einige Pfade können jedoch nicht geschützt werden, da der Benutzer noch nicht angemeldet ist. Wie die Anmeldeseite, der auth-callback Pfad und der Zugriff verweigert Pfad.

Da der auth-callback Weg nicht erreicht werden kann, wird der Benutzer noch nicht authentifiziert und wird es nie sein, wird der Benutzer auf den Standard AccessDenied Seite umgeleitet. Ich glaube das ist /Account/AccessDenied. Das ist auch geschützt, was die Identität erneut herausfordert, etc.

Ich denke, Ihr Problem ist gelöst, wenn Sie anonymen Zugriff auf die /Account/AccessDenied Pfad und auth-callback Pfad erlauben.

Die erste ist die tatsächliche Anmeldung des Benutzers und die zweite ist die Rekursion stoppen.

Im Code /Account/AccessDenied können Sie bestimmen, wie Sie darauf reagieren. Weil authentifizierte Benutzer auch hier landen können, wenn ein Anspruch fehlt, z. Benutzer ist authentifiziert, ist aber kein Administrator. Oder der Benutzer ist authentifiziert, hat aber keine Ansprüche für diese Website.

+0

Ich habe es schon gelöst, danke! Es hat nichts mit dem Account zu tun.Machen Sie einfach die Umleitung uri =>/signin-oidc ungeschützt, rufen Sie userManager.completeAuthentication.then (router.navigate (/ urltowhichIwantedbeforefore); in der SigninOidcComponent und das ist es :-) – Elisabeth

Verwandte Themen