Session management mit einer oder zwei Tabellen?
-
Moin,
Ich beende gerade die Arbeiten an einem LogInSystem für eine(meine) Webside und frage mich gerade über den Nutzen einer weitern Tabelle. Also folgendes:
Ich habe eine Usertabelle und eine Temp-Tabelle. in der TempTabelle wird eine SessionID mit den Daten, die bei dem LogIn eingegeben wurden gespeichert. (SessionID auch im cookie)
Nun muss ich erst den entsprechenden Namen per SessionID suchen und dann damit den User in der Usertabelle suchen, wenn ich z.B. User Einstellungen ändern möchte.Einfacher wäre es, die SessionID sofort in der Usertabelle mit zu speichern und danach zu suchen, aber ist das dann auch noch sicher bzw. genauso sicher wie mit zwei Tabellen?
Also in beiden fällen muss man ja "nur" an die SessionID kommen und hätte schon rechte wie ein angemeldeter Benutzer.dankö
-
Pille456 schrieb:
Ich beende gerade die Arbeiten an einem LogInSystem für eine(meine) Webside
Eine Webside wäre etwas anderes
Du meinst wohl Website?
Einfacher wäre es, die SessionID sofort in der Usertabelle mit zu speichern und danach zu suchen
Nicht nur sinnvoller, sondern auch weniger redundant, intuitiver und schneller
aber ist das dann auch noch sicher bzw. genauso sicher wie mit zwei Tabellen?
Was hat das mit Sicherheit zu tun? Du hast eine SessionID, und anhand derer bekommst du den Benutzer. Ob du das nun mit 20 Queries oder mit einer einzigen löst, hat Einfluss auf vieles. Auf die Performance. Auf die Umsetzung der Normalisierungsregeln. Auf die Eleganz der Lösung vielleicht auch. Aber auf die Sicherheit eher nicht
Vorausgesetzt natürlich, keines der SQL-Statements lässt Injections zu ...Also in beiden fällen muss man ja "nur" an die SessionID kommen und hätte schon rechte wie ein angemeldeter Benutzer.
Korrekt.
-
Jo, ich meinte website
Habs nun auch alles umgebaut, denke so isses besser
Um das Klauen der ID zu erschweren werde ich wohl noch die LogIn-Time speichern und ebenfalls checken. So muss der Angreifer immerhin wissen, wann sich ein Admin eingeloggt hat bzw. alle Möglichkeiten erst Zeitaufwändig durchprobieren.
-
Wieso sollte es besser sein die SessionID in der User-Tabelle zu speichern?
Wenn Du 2 Tabellen hast (User- und Session-Tabelle) geht es auch mit einem Query, musst halt die beiden Tabellen joinen und fertig.
Wenn Du die SessionID direkt in der User-Tabelle speicherst, dann kann jeder Benutzer sich nur mit einer Session einloggen, was ich persönlich als Nachteile sehe. Kann sein, dass es so gewollt ist, dann wäre das evtl. der bessere Weg, aber warum sollte man das wollen?
Eine simple Tabelle, wo SessionID, UserID und Timeout gespeichert wird wäre doch viel praktischer. Zum Beispiel zum parallelen Testen in verschiedenen Browsern etc. wäre es viel angenehmer, wenn man sich gleichzeit mit mehreren Sessions einloggen könnte.
-
mantiz schrieb:
Wieso sollte es besser sein die SessionID in der User-Tabelle zu speichern?
Stichwort Redundanz. Sonst ist es absolut wurscht, ob er die gleiche Tabelle verwendet oder nicht, es sei denn:
mantiz schrieb:
Zum Beispiel zum parallelen Testen in verschiedenen Browsern etc. wäre es viel angenehmer, wenn man sich gleichzeit mit mehreren Sessions einloggen könnte.
Aber das ist in Produktivumgebungen oft nicht erwünscht (Session Riding, Fixation etc.), und abgesehen davon war es nicht gefragt
mantiz schrieb:
Wenn Du 2 Tabellen hast (User- und Session-Tabelle) geht es auch mit einem Query, musst halt die beiden Tabellen joinen und fertig.
Es schon ein Unterschied ist
mantiz schrieb:
Wenn Du die SessionID direkt in der User-Tabelle speicherst, dann kann jeder Benutzer sich nur mit einer Session einloggen, was ich persönlich als Nachteile sehe. Kann sein, dass es so gewollt ist, dann wäre das evtl. der bessere Weg, aber warum sollte man das wollen?
Verstehe ich nicht. Ob es nun eine Tabelle mit einer eindeutigen Assoziation userId<->sessionId gibt, oder diese Assoziation dadurch hergesellt wird, dass die Users-Tabelle ein Feld namens sessionId besitzt, macht imho keinen Unterschied. Es kommt drauf an, wie der Login- und das Authentifizierungssystem implementiert sind, aber die Speicherung der Daten sollte so eigentlich keinen wirklichen Unterschied machen.
Ansonsten hast du aber natürlich recht - Will man multiple Logins, so ist eine separate Tabelle nützlich. Aber auch da nicht erzwungen, denn multiple Logins setzen immer noch unterschiedliche Browser voraus, und somit ließe sich das ins Session Management auch mit einer Tabelle integrieren.
-
Naja, soweit OK, aber ich würde mir die Möglichkeit nicht verbauen wollen, dass der gleiche Benutzer sich 2 mal einloggt. Gibt die verschiedensten Gründe dafür.
Wenn man jetzt nur eine Session vorsieht, dann kicken sich die User gegenseitig raus.
Aber ist wohl jedem selbst überlassen, wollte nur darauf hinweisen, also in diesem Sinne: Macht was ihr wollt.
-
mantiz schrieb:
Aber ist wohl jedem selbst überlassen, wollte nur darauf hinweisen
Das ist auch völlig berechtigt und gut so; und du hast ja letztendlich auch Recht
Besonders wenn noch weitere Daten zur Session gespeichert werden sollen - Login Time, Ip Range (Achtung! Nicht zur Validierung der Session verwenden!!), Browser etc. - bietet sich die Auslagerung in eine Tabelle sehr an!