2017-07-13 3 views
0

Ich baue eine Dart/Aqueduct Webapp, in der ich den Zugriff auf bestimmte Routen beschränken muss. Ich benutze Aqueducts Authorizers für den Fall, dass eine HTTP-Anfrage gestellt wird, aber ich bin ein wenig besorgt über die Kontrolle des Benutzerzugriffs innerhalb der Dart App selbst.Sichern von Routen in Dart Webapp

Wenn auf verschiedenen Seiten innerhalb der Webapp Routing verwende ich Dart-Routing, das heißt:

const Route(path: '/heroes', name: 'Heroes', component: HeroesComponent) 

Dies ermöglicht es mir, eine andere Vorlage und Komponente in einer neuen URL zu verwenden, jedoch gibt es keine HTTP-Anforderung gemacht. Gibt es eine Möglichkeit, Benutzerbereiche effektiv zu implementieren, sobald sich der Benutzer in der App befindet?

Ich überlegte, das Zugriffstoken auf die Initialisierung der gerouteten Komponenten zu überprüfen und die Informationen nicht anzuzeigen, wenn der Benutzer nicht authentifiziert ist, aber der Benutzer immer noch Zugriff auf den Seiteninhalt hat, da Dart-Webapps in einem vorkompilierten enthalten sind JS-Paket?

+0

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')' –

Antwort

0

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.

+0

Danke für Ihre ausgezeichneten Antworten Joe. Ich werde versuchen, den Vorschlag von Günter zu verwenden und nach einer 401-Antwort beim Abrufen meiner Daten zu suchen, um sicherzustellen, dass der Benutzer authentifiziert ist. –

0

Sie können zwei Anwendungen erstellen - eine, die im Grunde nur die Anmeldungs-/Anmeldeseite enthält, und eine mit Ihrer geschützten Funktionalität.

Sie müssen Code auf dem Server schreiben, damit nur authentifizierte Benutzer die geschützte App sehen können. Anderenfalls möchten Sie vielleicht eine 403 werfen oder Gäste auf eine Anmeldeseite umleiten.

Hoffe, das hilft.