AngularJS fängt keine direkten Anfragen von der Adressleiste ab

9

Ich erstelle eine AngularJS-Anwendung, die das JWT-Token für die Authentifizierung verwendet. Das Token wird mit dem AngularJS-Interceptor wie unten gezeigt übertragen.

%Vor%

Wenn ich auf /restricted Seiten zugreife, funktioniert alles einwandfrei. Das Problem ist, wenn ich auf die Seite /restricted gehe, indem ich die URL direkt in die Adressleiste eintippe (oder die Seite aktualisiere), dann wird AngularJS umgangen und damit die Interceptors nicht Abfangen der Anfrage und das Token wird nicht übergeben.

Ich habe eine Weile gesucht, ich habe einige Lösungen gefunden, wie mit einem Code zu antworten, der das AngularJS lädt und dann von dort eine Umleitung macht. Allerdings suche ich, wenn möglich, nach einem einfacheren / saubereren Ansatz, da mir hier etwas fehlen könnte.

Ich kann erkennen, ob die Anfrage von AngularJS kam oder nicht, indem ich nach x-access-token suche, da ich sie immer übergebe (leerer Wert, wenn der Benutzer nicht authentifiziert ist).

Lösung

Alex 'Antwort zeigt auf das genaue Problem, danke Alex.

Ich habe es gestern herausgefunden. Die Lösung, mit der ich ging, war sicherzustellen, dass alle Anfragen von AngularJS kommen, ich habe eine Liste der eingeschränkten Seiten, wenn eine von ihnen angefordert wird, rufe ich eine Funktion auf, um das JWT-Token auf Serverseite zu überprüfen und zu validieren Es ist gültig, gehen Sie weiter, andernfalls gehen Sie zur Anmeldeseite. Das Wichtigste ist, dass ALLE Anfragen an die index.html gesendet werden, um sicherzustellen, dass AngularJS das Routing bearbeitet.

Dieser Link hat mir sehr geholfen, dieses Problem zu lösen.

Ссылка

    
NightwareSystems 22.06.2015, 19:30
quelle

4 Antworten

2

Es klingt so, als gäbe es eine Verwechslung zwischen Angulars Router und Server-Endpunkten.

Wahrscheinlich lösen Sie beim Navigieren durch die Anwendung die $ http-Konfiguration aus, indem Sie URLs verwenden, die von Angulars Router verfolgt werden (was gut funktioniert), während die /restricted URLs Server URLs sind.

Wenn Sie also nach etwas /restricted außerhalb der Angular-App (im Browser) fragen, sendet es die Anfrage direkt an den Server und nicht über den Angular-Router oder die Anwendung.

Grundsätzlich müssen Sie in Ihrer Angular-App Routen erstellen, die sich im Kontext restricted befinden. Wenn Sie diese Option initialisiert haben, führen Sie die $ http-Konfiguration aus. Sie sollten niemals Server-Endpunkte direkt in der Adressleiste aufrufen, außer für index.html ( / ).

Ich würde vorschlagen, eine eckige Route namens /restricted-area zu haben, so dass, wenn ein Benutzer sie trifft, diese immer die $ http-Methoden verwendet, indem sie eine dedizierte Angular-Route verwenden und intern den /restricted Endpunkt des Servers aufrufen. über einen Controller.

    
Alex 02.07.2015, 08:08
quelle
2

Ich hatte die ähnliche Frage vor zwei Monaten gestellt. Was ich verstanden habe, ist normalerweise, dass JavaScript-Frontend-Frameworks wie die http-Anfrage bedient wurden:

  • Wir geben eine URL in die Adressleiste ein.
  • Der Browser sendet die Anfrage.
  • Der Server erhält die Anfrage.
  • liefert die notwendigen html, js und css Dateien.
  • browser rendert es.

Aber als die kürzliche Umstellung auf verschiedene Javascript-Frontend-Frameworks und die Verwendung von RESTful-APIs begonnen hat, muss die Anfrage einen Berechtigungsheader haben. So in vielen der einzelnen Seite Web-Anwendungen mit JavaScript-Frameworks wie angularjs,

  • die erste Anfrage für '/' Router wird gesendet
  • Der Server versorgt die Webanwendung mit Ihrem Browser
  • all das weitere Routing in der Webanwendung erfolgt innerhalb Ihrer Frontend-Anwendung, daher das "#" nach Ihrer URL.
  • Anfragen werden von der Anwendung zum Abrufen, Aktualisieren, Löschen oder Posten von Ihrer Anwendung über angular js gestellt.

Also wenn Sie eine Anfrage aus eckiger Anwendung machen. Ihre Anfrage wird von der eckigen Anwendung abgefangen und von Ihrem Interzeptor abgefangen. Wenn Sie die URL jedoch über die Adressleiste eingeben, sendet der Browser die Anfrage direkt an den Server, da der Browser zu diesem Zeitpunkt der Anfrage noch nicht Ihre eckige Webanwendung geladen hat.

Ich schlage vor, dass Sie html5mode auf false setzen und vor Ihrer Route ein # setzen.

wie localhost/#/restricted und führe das Routing von deinem Routenanbieter aus. Wenn # vor Ihrer Route vorhanden ist, wird die Anforderung für / an den Server gesendet, Ihre Anwendung wird geladen und einige Controller in /restricted von Ihrer Anwendung veranlassen eine HTTP-Anforderung an den gewünschten Serverendpunkt. Auf diese Weise wird die Anfrage über Ihre Anwendung gesendet und von Ihrem Interceptor abgefangen. Das Aktualisieren und direkte Eingeben der Adresse in die Adressleiste funktioniert ebenfalls.

    
Pravin 02.07.2015 11:51
quelle
0

Ich nehme an, wenn Sie auf die Seite / restricted zugreifen, wird Ihre Angular App korrekt gestartet und es ist nur ein Login-Problem.

Wenn Sie kein Token haben, müssen Sie auf die Anmeldeseite umleiten. Sie können den Login als ein modales Overlay anzeigen, ohne dass Sie die Seite wechseln müssen. Der Interceptor überwacht das Response-Ergebnis für den Status 401. In diesem Fall zeigt der Interceptor das Login an. Nach der erfolgreichen Anmeldung führt der Interceptor die Ursprungsanfrage aus - mit dem Token .

Sie finden ein funktionierendes Beispiel in angular App

    
Michael 02.07.2015 07:49
quelle
-2

Übergeben Sie dieses Token nur in Cookies, nicht im Header.

    
Petr Averyanov 29.06.2015 17:40
quelle