Django Sessions mit AWS Cognito

Django, Flask, Bottle, WSGI, CGI…
Antworten
stre
User
Beiträge: 7
Registriert: Samstag 11. Februar 2017, 15:24

Hallo miteinander!

Ich befasse mich seit kurzem mit Django und stecke gerade etwas fest deswegen hier meine Frage:
Ich verwende Django als Framework und lass es in der AWS-Cloud laufen. Für die Benutzerverwaltung verwende ich AWS Cognito. Wenn man sich über Cognito einloggt bekommt man einen AccessToken (ca. 900 Zeichen) und einen RefreshToken (ca. 1700 Zeichen) zurück geliefert mit denen man im späteren Verlauf die Userdaten immer wieder anfordern kann. Bisher habe ich diese beiden Werte über eine Django Session (COOKIE-based) gespeichert und greife immer wieder darauf zu.
Macht das Sinn oder wäre es nicht sowieso gleich sicher einfach die zwei Token als Cookies zu speichern?

Das Problem liegt darin, dass ich zwei verschiedene Logins habe und die Cookie-Session nicht groß genug ist um alle 4 Token darin zu speichern aber wenn ich sie in der Datenbank speichere verursacht das ja unnötigen DB-Traffic oder?

Vielen Dank!
Konstantin
BlackJack

@stre: Definiere ”unnötig”. Wenn Du die Daten nicht als Cookie speichern kannst weil sie zu gross sind, und sie deshalb in der DB speicherst, dann ist es nötig auf die DB zuzugreifen um an die Daten zu kommen. Anders herum könnte man ja auch sagen das die Daten als Cookies unnötigerweise immer zum Client und zurück geschickt werden wenn man sie als Cookies speichert. Zudem bekommt der Client diese Daten in die Finger, was vielleicht auch nicht in jedem Fall wünschenswert ist.
stre
User
Beiträge: 7
Registriert: Samstag 11. Februar 2017, 15:24

@BlackJack:

mit unnötig meine ich, dass dann ja jedes mal, wenn der User eine andere Seite aufruft einen Datenbankzugriff brauche und wenn das eine Anwendung mit vielen Usern ist dann wird der Datenbankserver ja auch dementsprechend skaliert werden müssen oder? Diese Kosten würde ich mir ja sparen wenn ich die Daten lokal als Cookies speichere. Zum Thema Sicherheit denk ich mir, dass der eigene User den AccessToken der eine Stunde gültig ist und den ewig langen RefreshToken wohl kaum so verändern können wird, dass er Zugriff auf die Daten eines anderen Users erhalten kann und wenn der Computer eines Users angegriffen wird dann wäre es dem Angreifer ja auch möglich auf der Webseite mit dem Useraccount des Opfers zu arbeiten - egal ob nun die session gespeichert ist oder die Token..
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

Zum ersten ist eine Webanwendung, welche bei jedem Besuch eine DB-Abfrage abfeuert beileibe nichts ungewoehnliches. Und wenn sie auch nur *irgendetwas* sinnvolles mit dem Login anfangen soll jenseits von "Hallo Karl-Heinz" auf die Seite zu schreiben, werden da eh noch deutlich mehr hinzukommen. Da jetzt so frueh zu micro-optimieren halte ich fuer verschwendete Zeit, aber YMMV. Und letztlich stellt sich natuerlich die Frage der Alternative. Wenn du keinen Platz in den Cookies hast, musst du wohl oder uebel irgendwo die Daten cachen. Das kann auch kein KV-Storage sein oder aehnliches, aber letztlich ist das alles eine Sosse bezueglich der benoetigten Ressourcen.
stre
User
Beiträge: 7
Registriert: Samstag 11. Februar 2017, 15:24

okay stimmt auch wieder - also würdest du einfach auf die database-engine zurückgreifen?
BlackJack

@stre: Ich würde einfach erst einmal die Sessions von Django benutzen und erst über Optimierungen nachdenken wenn das tatsächlich messbar ein Problem wird.
stre
User
Beiträge: 7
Registriert: Samstag 11. Februar 2017, 15:24

okay vielen Dank für eure Hilfe! :)
Antworten