2017-11-14 3 views
5

Ich habe eine Web-API in .net Core 1.0, die JWT-Token (access_token) bei der Anmeldung an die Clients ausgibt. Jetzt hat das Token eine kurze Ablaufzeit (10 Minuten) und der Client fordert alle 8 Minuten ein neues Token für die Kontinuität der Sitzung an. Dieses Token wird im Cookie auf der Clientseite im Browser gespeichert. Jetzt funktioniert das gut, wenn der Client in nur einem Tab des Browsers funktioniert. Wenn der Client jedoch zwei oder mehr Registerkarten öffnet, wird alle acht Minuten eine Anforderung für ein neues Token an die API gesendet. Dies führt zu mehreren Anfragen von demselben Benutzer gleichzeitig und meine Anwendung gibt Token für jede Anfrage aus, aber nur eines der Token wird auf dem clientseitigen Cookie gespeichert. Es führt jedoch zu mehreren Token, von denen nur ein einziger während seiner gesamten Lebensdauer verwendet wird.Wie kann die API nur einen Token pro Benutzer ausgeben lassen (in mehreren Tabs geöffnet)?

Ich habe versucht, die userId und das Token in der DB zu speichern und sie während der API-Anfrage zu überprüfen, aber der gleiche Benutzer in mehreren Registerkarten macht gleichzeitige Anfrage und die Logik schlägt hier fehl.

Wie kann ich diese Situation beheben? Ich möchte, dass meine API nur einen Token pro Nutzer ausgibt, der auf mehreren Tabs geöffnet ist. Jede Hilfe wird geschätzt.

+0

Also möchten Sie, dass Ihre API für jede Benutzeranforderung ein einzelnes Token ausgibt, auch wenn sie mehrere Tabs geöffnet haben? – Shaw

+0

Ja, für denselben Benutzer, der in mehreren Registerkarten geöffnet wurde. – saurabhadhikari

+3

Sie müssen die Token betweeb Tabs teilen. Das Front-End sollte es wiederverwenden, wenn es verfügbar ist, oder ein neues anfordern und es den restlichen Tabs zur Verfügung stellen. Dies kann mit localStorage anstelle von cookie und events geschehen, um eine Änderung zu kommunizieren. Siehe https://stackoverflow.com/questions/20325763/browser-sessionstorage-share-between-tabs – pedrofb

Antwort

0

Dies ist schwierig. Wenn Sie versuchen, das Token in der DB zu speichern und kein neues Token auszugeben, bis das alte abläuft, wird es eine Fülle von Problemen erzeugen. Denken Sie an den Fall, wenn der Benutzer mehrere Geräte verwendet. Diese Logik wird nicht funktionieren. Es gibt viele weitere Fälle.

Und das Speichern der JWT im Server ist sehr redundant und kontraintuitiv, IMO. Einer der Hauptvorteile von JWT ist, dass Sie nicht jedes Mal, wenn eine geschützte Ressource angefordert wird, einen DB-Aufruf durchführen müssen. Das JWT selbst verfügt über alle Informationen zur Autorisierung des Benutzers.

glaube ich, ist die Lösung, die Sie suchen Drosselung oder Rate begrenzen. Sie können den Token-Issue-Endpunkt auf 1request/sec/ip begrenzen (experimentieren Sie und finden Sie die Rate, die gut funktioniert). Die Idee besteht darin, gleichzeitige Anfragen nach neuen Token-Problemen von derselben IP-Adresse zu blockieren und nur eine davon zu verarbeiten. Sie erreichen dies durch IIS oder Attributes. Spielen Sie herum und sehen Sie, was am besten für Sie funktioniert.

Verwandte Themen