Verzeihen Sie, wenn ich Ihre Frage missverstanden habe oder Sie das meiste bereits wissen, aber es klingt wie Sie nach der Unterscheidung zwischen Daten, die von einer Anwendung und der Anwendung selbst angezeigt werden. Oder allgemeiner der Unterschied zwischen einer einzelnen Seitenanwendung und einer serverseitig gerenderten Seite.
In einer serverseitigen Rendering-Anwendung lädt jede Navigation eine neue URL vom Server (oder Cache). Der Server verwendet Berechtigungsinformationen aus der Anforderung, um die entsprechenden Daten abzurufen, sie in eine HTML-Templateseite einzufügen und dann diese Seite zurückzugeben. Laut dem Kunden sind die Daten, die die Seite anzeigt, und die Seite selbst eine einzige Einheit. Wenn die Daten nicht abgerufen werden können, wird eine andere Seite zurückgegeben, die angibt, dass der Benutzer keinen Zugriff hat.
In einer einseitigen Anwendung wird jede mögliche 'Seite', zu der Sie navigieren können, einmal heruntergeladen und es fehlen Ihnen alle tatsächlichen Daten. Diese Seiten sind stattdessen ein Container für Daten. Das Verhalten dieser Seiten macht API-Anforderungen an den Server, damit die Daten angezeigt werden.
Die Anwendung selbst ist nicht geschützt - jeder kann zu ihm oder einer seiner Seiten navigieren. Die Daten sind jedoch geschützt. Wenn der Benutzer keinen Zugriff auf die von einem API-Aufruf angeforderten Daten hat, wird ein 401-Statuscode mit dem JSON-Fehlertext zurückgegeben.
Daher muss zwischen den Client- und Server-seitigen Routen unterschieden werden. Sie haben bereits bemerkt, dass clientseitige Routen keine HTTP-Anfrage stellen - dies ist beabsichtigt.
Wenn Sie die Anwendung und die API aus der gleichen Anwendung bedienen, ist es eine gute Idee, alle Ihre API-Routen mit etwas wie /api
voranstellen. Die clientseitige Route ist beispielsweise /heroes
und die serverseitige Route ist /api/heroes
. Dies ermöglicht auch, dass eine mobile Anwendung (oder jede andere nicht browserbasierte Anwendung) Ihre API verwendet. Sie werden den HTML-Code nicht benötigen, da sie ein eigenes Renderverhalten haben.
Wie Günter sagte, wenn es eine Seite gibt, die ohne Zugriff auf die API-Daten nutzlos ist, punt sie zurück auf eine Login-Seite.Es gibt zwei Szenarien, in denen Sie keinen Zugriff auf API-Daten haben: Sie haben überhaupt kein Zugriffstoken und Ihr Zugriffstoken ist abgelaufen.
Machen Sie die API-Anforderung, wenn Sie zur clientseitigen Route /heroes
navigieren. Wenn Sie kein Zugriffstoken haben, stempeln Sie sie auf eine Anmeldeseite. Wenn die Anfrage eine 401 ergibt, stempelt sie sie auf eine Anmeldeseite zurück. Wenn Sie 200 zurückbekommen, arbeiten Sie wie gewohnt.
Ein Ort, an dem clientseitiges Routing in die Quere kommt, ist der Versuch, eine clientseitige Routen-URL in einen Browser einzugeben (im Gegensatz zur programmgesteuerten Navigation). Es gibt verschiedene Strategien, um dies zu umgehen, hier ist eine: https://github.com/stablekernel/aqueduct/issues/274.
Sie können die Annotation '@CanActivate()' verwenden. Es ist ein bisschen umständlich, weil die Verwendung von DI dort einen hässlichen Hack erfordert. Aber es ist nicht zu kompliziert. Sie können auch eine Prüfung zu einer Komponente hinzufügen, wenn der Benutzer angemeldet ist und wenn nicht, rufen Sie einfach 'router.navigate ('/ login')' –