#1 25. November 2009 Login-System, SessionID in DB oder nicht? Hallo Leute, ich und ein Kumpel wollen ein Projekt stemmen. Bei diesem wird natürlich auch ein LoginSystem bzw. eine Benutzerverwaltung benötigt. Ich habe bereits 2 LoginSysteme geschrieben. Jedesmal habe ich die SessionID in der Datenbank(mysql) gespeiechert. Mein Kumpel brachte die Überlegung, dass man die SessionID ja gar nicht in der DB halten muss, funktioniert ja auch so(is mir vorher noch nie wirklich aufgefallen ). Jetzt die Frage: Was ist besser? SessionID des Benutzers in der DB halten oder nicht? Gibts Vor- und Nachteile / Pro&Contra ? Ich hoffe ihr könnt mir weiterhelfen PS: Habe im Netz gelesen dass es Schneller und sicherer sei die SessionID in der DB zu halten, kann das allerdings nicht ganz nachvollziehen. + Multi-Zitat Zitieren
#2 25. November 2009 AW: Login-System, SessionID in DB oder nicht? Zusammen mit welchen Informationen speicherst du SessionID? Wenn du es zusammen mit der IP speicherst, kannst du nachher überprüfen oder der User mit der SessionID auch der von vorhin ist - man kann sich so nicht über die Session von jmd anderem einloggen. + Multi-Zitat Zitieren
#3 25. November 2009 AW: Login-System, SessionID in DB oder nicht? für kleinere benutzersysteme reicht das in php implementierte session-system vollkommen aus. du brauchst im grunde überhaupt nichts in der db speichern denn selbst die ip des benutzers kannst du in den session-variablen speichern und abgleichen. für professionelle systeme ist eine datenbank-lösung vorzuziehen, denn damit kannst du eine benutzer-session auf verschiedenen servern initialisieren und wiederverwenden. + Multi-Zitat Zitieren
#4 25. November 2009 AW: Login-System, SessionID in DB oder nicht? Hallo frankred, kleine frage: soll das Projekt local oder public laufen? Wenn du Sessions benutzen willst, dann muss die SessionID auf dem Server gespeichert werden! Dateisystem oder Datenbank. + Multi-Zitat Zitieren
#5 25. November 2009 AW: Login-System, SessionID in DB oder nicht? Und zwar weil ?( + Multi-Zitat Zitieren
#6 25. November 2009 AW: Login-System, SessionID in DB oder nicht? meinst du das ernst? wo sollen die daten sonst hin? + Multi-Zitat Zitieren
#7 25. November 2009 AW: Login-System, SessionID in DB oder nicht? ja aber wieso überhaupt speichern? murdoc hat es zwar schon gesagt mit guter begründung aber deine aussage klingt so allgemein... + Multi-Zitat Zitieren
#8 25. November 2009 AW: Login-System, SessionID in DB oder nicht? PHP: Sessions - Manual durchlesen alle daten werden auf dem server gespeichert. die session-id wird via set-cookie an den client übergeben, welcher bei jedem nachfolgenden request eben diese wieder an den server sendet. auf dem server liest die php-engine anschließend anhand der session-id den entsprechenden session-cache aus und importiert in den aufgerufenen php-prozess alle gespeicherten inhalte in einer globalen variablen namens $_SESSION. auf dem client wird lediglich die session-id gepeichert (falls erwünscht). der session-cache befindet sich btw in einer datei im ordner "tmp" und beinhaltet alle daten der session in einer serialisierten form (ähnlich wie PHP: serialize - Manual <- aber im normalfall nicht kompatibel dazu) + Multi-Zitat Zitieren
#9 25. November 2009 AW: Login-System, SessionID in DB oder nicht? @Alle, Danke für eure Antworten, aber irgendwie bin ich immer noch nicht wirklich schlauer . @powernator: ich speichere die Session ID in der Tabelle SessionID durch JOINS ist diese mit den Benutzern verbunden! also jeder Benutzer kann eventuell mehrere SessionIDs haben (für Multi Login) @funland: das Projekt soll Public und Lokal laufen, versteh jedoch deine Suggestion nicht. Das ist mir schon klar dass ich die SessionID sonst irgendwo speichern muss @Murdoc: Ja das ist mir schon klar wie die Session gespeichert wird und was sich darin befindet. Also wie ich dich richtig verstanden habe "Murdoc" sollte ich schon eher die DB verwenden: siehe dein Zitat: + Multi-Zitat Zitieren
#10 25. November 2009 AW: Login-System, SessionID in DB oder nicht? genau das meinte ich, aber halt im allgemeinen ist gibts natürlich auch sessionhandler oder auch "clientmanager" die nicht auf PHP-Session angewiesen sind. Die auch schneller sowie sicherer sind. + Multi-Zitat Zitieren
#11 25. November 2009 AW: Login-System, SessionID in DB oder nicht? sicherer - okay, das kommt auf den programmierer an schneller - das halt ich für ein gerücht immerhin ist das php-session-system nativ implementiert (in c), da kommt keine datenbank mit. der einzige vorteil einer datenbank-lösung ist einfach, dass man benutzersessions auf verschiedenen servern fortführen kann - solange alle server zugriff auf die gleiche datenbank haben! z.b.: http://foo.bar.de/ -> startet die session, http://baz.bar.de/ -> kann session von foo.bar.de wiederaufnehmen. mit ein wenig frickelarbeit würde man das php-session-system auch zum laufen bekommen (wenn alle server im selben netzwerk sind), aber via db bleibt deine applikation besser skalierbar. //edit - klar kann man auch den client mit cookies zumüllen ^^ + Multi-Zitat Zitieren
#12 26. November 2009 AW: Login-System, SessionID in DB oder nicht? mit meinen ersten beitrag, wollte ich nicht zu tief in die seele der phpler greifen und eine große diskussion anfangen @tut mir leid. ich hab den ersten beitrag nicht so ganz verstanden, da er bei 2xLoginSyss(id in der datenbank gespeichert) und kumpel meinte "brauchst du nicht"... konnte man nicht gleich den kumpel fragen? das es bei php schon am board ist, ist es selbstverständlich ein vorteil. das ist auch fast der größte vorteil des managements. wenn man die kontrolle über den ganzen server verfügt nicht der einzigste vorteil @das kommt auf den programmierer an wenn man ein eigenes management verwendet, bei dem man bestimmen kann zb. was und wie es machen soll, kann man viel an der sicherheit und performance schrauben. aber wieder zu tief... und das letzte wäre es, den client mit cookies zuzumüllen! (ok: bis auf max. 2) + Multi-Zitat Zitieren
#13 26. November 2009 AW: Login-System, SessionID in DB oder nicht? Soweit ich weiß, ist das nicht erlaubt. IPs in Verbindung mit Benutzerdaten speichern. Und wenn doch, dann würde es auf jeden Fall Bedenken wegen dem Datenschutz geben. + Multi-Zitat Zitieren
#14 26. November 2009 AW: Login-System, SessionID in DB oder nicht? ip kann man ganz weglassen: 1. wie schon Hapablap erwähte: datenschutz. 2. proxys 3. manipulation und kleine frage an die mods: wurde die "Webentwicklung" bereinigt? waren genug beiträge zu dem thema vorhanden. + Multi-Zitat Zitieren
#15 26. November 2009 AW: Login-System, SessionID in DB oder nicht? wegen datenschutz: wenn man ein benutzersystem integriert, dann sollte man auf alle fälle eine datenschutzerklärung verfassen (lassen). ip's zusammen benutzerdaten zu speichern ist (afaik) nicht direkt verboten, wenn man wie bereits erwähnt die ganze sachlage in einer datenschutzerklärung schildert. und da sessions eh nur temporär eingesetzt und anschließend komplett gelöscht werden, sollte es keine bedenken seitens der benutzer geben. aber viel wichtiger ist das warum: es gibt benutzer die das setzen von cookies nicht zulassen, dann wird die session-id im normalfall via GET oder POST übertragen - wenn man hier nicht die ip abgleichen kann, dann kann jeder beliebiger benutzer die session stehlen und weiterverwenden. das passiert z.b.: wenn benutzer-a einen link inkl. session-id an benutzer-b weitergibt. nicht jeder internetbenutzer kann solche session-ids erkennen und ein manuelles rauslöschen wär ne zumutung. wenn man glück hat und google ein wenig durchforstet findet man manchmal auch links mit session-id's in den suchergebnissen, dann kann man (wenn man glück hat) auf der zielwebseite die session des googlebots wiederaufnehmen ^^ nö, du kannst unten einstellen bis welchen zeitraum du themen anzeigen lassen möchtest. die meisten themen sind einfach zu alt und werden nicht mehr gelistet + Multi-Zitat Zitieren
#16 27. November 2009 AW: Login-System, SessionID in DB oder nicht? denke das ca. 95% aller nutzer cookies akzeptieren. cookies gehören ja zum http/https-header(request,response). meiner meinung nach sollte man die SessionID nur in cookies ablegen und nicht per url weitergeben. kein cookie, keine session. bessergesagt die session erst dann starten, wenn z.b. der benutzer sich erfolgreich eingeloggt hat oder ein cookie mit gültiger SessionID besitzt. nicht auf jeder seite einfach session_start() verwenden, da es bei jedem aufruf eine SessionID erzeugt wird falls der benutzer keine cookies akzeptiert oder seine ip sich städnig wechselt(aol-user). + Multi-Zitat Zitieren