login

[Gast]

Shade Of Mine schrieb:

Warum speicherst du die Session ID in der Datenbank?

Die Daten sollten in der Session gespeichert werden (ob die Session jetzt in einer DB oder PlaintextFiles liegt ist dabei unerheblich).

Weil wie bereits gesagt, die Session immer vom Hoster abhängt! Entweder ist sie zeitlich begrenzt, oder es ist nur eine definierte Anzahl Sessions erlaubt! Die Session tatsächlich in sich selbst zu speichern halt ich auch für tödlich! Zu schnell passiert es, dass eine Session abläuft!
Ich finde, die SessionID zu generieren und in Verbindung mit dem akutellen Timestamp zu hashen, das ganze dann in der DB zu speichern, ist die beste Lösung...

VlG

[Sqwan]

damit könnte es aber die möglichkeit geben das es 2 gleiche session_ids gibt oder nicht. Für mich klingt das von der beschreibung her jetzt nach ner sicherheits lücke. Wenn mich dafür aber zu wenig damit aus.

Wie is bei kostenpflichtigen servern in der regel aussieht kann ich dir aber sagen. Du kannst einfach einstellen wie lange eine session läuft. z.B. 15 min.
Und dann ist die auch immer 15 min

[Shade Of Mine]

Wie lange Sessions gueltig sind ist eine Option:
session.gc_maxlifetime

Erzaehlt also bitte nicht irgendeinen Bloedsinn mit Sachen in der Datenbank speichern wenn dafuer die Session gedacht ist. Wenn ein Server schlecht konfiguriert ist, ist das vielleicht aergerlich und ein Workaround wird noetig, aber es ist nichts womit man Leute verwirren sollte.

Und was soll Session ID und Timestamp hashen bringen?
Die Session ID identifiziert die mit der Session verknuepften Daten - da braucht es keinen Hash. Wenn man das PHP Session System nicht benutzen will, dann schreibt man sich sein eigenes Session System und auch dort identifiziert die Session ID die Daten die mit der Session Verknuepft sind.

Das ist auch keine Sicherheitsluecke oder so. Das einzige "Problem" ist das generieren der Session ID - hier muss man aufpassen.

[Unix-Tom]

Und eine Session läuft nur dann ab wenn der User damit nichts mehr macht.
Sollte er bis zum ablauf auf der Webseite verweilen ohne was zu machen dann ist er entweder weg oder die Seite hat keine Content.

[Gast]

Shade Of Mine schrieb:

Erzaehlt also bitte nicht irgendeinen Bloedsinn mit Sachen in der Datenbank speichern wenn dafuer die Session gedacht ist. Wenn ein Server schlecht konfiguriert ist, ist das vielleicht aergerlich und ein Workaround wird noetig, aber es ist nichts womit man Leute verwirren sollte.

Uhh, das ist gemein. Speichere nichts in Sessions wenn dafür Datenbanken gedacht sind! Merkste was?

Shade Of Mine schrieb:

Und was soll Session ID und Timestamp hashen bringen?

Hmm, Moment! Da muss ich jetzt ganz scharf nachdenken......
Ah, ich habs! EINDEUTIGKEIT? Vielleicht?

VlG

[Simon Petrus]

Und wenn der Browser des Besuchers - wie hier auf unseren Firmenrechnern - keine Cookies annimmt?

[Shade Of Mine]

RandomAccess85 schrieb:

Shade Of Mine schrieb:

Erzaehlt also bitte nicht irgendeinen Bloedsinn mit Sachen in der Datenbank speichern wenn dafuer die Session gedacht ist. Wenn ein Server schlecht konfiguriert ist, ist das vielleicht aergerlich und ein Workaround wird noetig, aber es ist nichts womit man Leute verwirren sollte.

Uhh, das ist gemein. Speichere nichts in Sessions wenn dafür Datenbanken gedacht sind! Merkste was?

Wenn du die Session ID in die DB speicherst um die Daten Anhand der Session ID aus der Datenbank zu holen, hast du effektiv die mit der Session ID verknüpften Daten in 2 unterschiedlichen Systemen abgelegt. Das ist nicht clever.

Du kannst die Session natürlich in die DB reinschreiben, da spricht ja nichts dagegen. Du sollst nur die Session Daten nicht trennen. Das macht nur Probleme.

Was ich meine ist: $_SESSION zu verwenden und zusätzlich noch Daten zu der Session in eine Datenbank zu schreiben. Alle Session Daten müssen zusammenbleiben. Ob die jetzt in einer DB, Plaintextfiles oder auf einem Reisfeld liegen ist dabei egal.

Das PHP Session Management bietet sich halt an - mit eigenen Handlern wenn man die Daten in einer DB haben will. Aber Session Management von PHP mit Files nutzen und dan extra Daten in eine DB schreiben, das schreit nach Fehlern.

Shade Of Mine schrieb:

Und was soll Session ID und Timestamp hashen bringen?

Hmm, Moment! Da muss ich jetzt ganz scharf nachdenken......
Ah, ich habs! EINDEUTIGKEIT? Vielleicht?

Erklär mir das mal. Eine Session ID ist bereits eindeutig.

@Simon Petrus:
Eine Session ID muss nicht in einem Cookie stehen. Die kann auch direkt per GET und POST immer weitergereicht werden. Bei PHP heisst dieses Features session_trans_id

[Gast]

Shade Of Mine schrieb:

Eine Session ID ist bereits eindeutig.

Beweis?

VlG

[volkard]

RandomAccess85 schrieb:

Shade Of Mine schrieb:

Eine Session ID ist bereits eindeutig.

Beweis?
VlG

Die soll so gemacht sein. Wenn nicht, ist sie nutzlos, und man muß erstmal dort weiterschrauben.

[Gast]

@Volkard:
Stell dir vor -> ich weiß! Ich habe um Beweise und nicht um unsinnige Kommantare gebeten Ich habe bei dir aber ehrlich gesagt auch nichts anderes erwartet

VlG

[volkard]

RandomAccess85 schrieb:

@Volkard:
Stell dir vor -> ich weiß! Ich habe um Beweise und nicht um unsinnige Kommantare gebeten Ich habe bei dir aber ehrlich gesagt auch nichts anderes erwartet

Um streng logisch zu bleiben: Ist die Eindeutigkeit der Session ID für Dich ein Axiom oder nur eine Definition?
~Wir erinnern uns kugelnd vor Spaß an die Frage "Würden noch mehr Messungen Ihre Theorie bekräftigen?" auf einem Physikerkongress.~

[Gast]

Ich schalt ab! Es wird albern

[zwutz]

natürlich ist eine ID eindeutig. Deswegen heißt sie ja ID. Wenn du einen Beweis willst, schnapp dir ein Lexikon

Wenn zwei Clients die selbe ID haben, haben sie auch die selbe Session und es ist irgendwas falschgelaufen.

Das kann man verhindern, aber ich sehe nicht, wie das verhashen mit dem aktuellen Timestamp dabei helfen sollte.

[ghostboss]

Hallo,

noch mals zu meinem "System", da ich damit angefangen habe (Session_id und DB).

Ich mach das so:
Wenn der User sich einloggt dan erstelle ich die Session_id und speichere sie in der Datenbank und im Cookie. So, und auf (allen) anderen Seiten hole ich (bzw. das Script) mir das Cookie mit der Session_id (23frt5...) und suche in der Datenbank nach der gleichen Session_id. Finde ich die Session_id in der Datenbank, dann hab ich den User. Wenn nicht gefunden, dann muss der User sich einloggen.

* In der $_SESSION speichere ich nichts, also keine getrennten Daten.

Und dieses "Login-System-mit-Cookies" hab ich nur gemacht weil, ich mich nicht auf die $_SESSION verlassen konnte als ich auf einem Freehoster programmiert habe. Da es so gut und übersichtlich funktioniert hat, hab ich es bei der nächsten Seite übernommen.

Werde aber später mal das mit $_SESSION versuchen.

[Gast]

Hallo,

es ist doch abartig wie ihr immer auf Lehrbuchwissen und Lehrbuchmethoden zurückgreift

Folgende Variante zum Erstellen einer SessionID...

srand(microtime()*1000000);
$zufall = rand(1,1000000);
$zufall=$zufall.$VielleichtNochDerNutzername; //Oder eben der aktuelle Timestamp
// Kann auch $zufall = session_id().$timestamp; sein
$session = MD5($zufall);

ist in etwa gleichzusetzen mit

session_start();
session_id();

Letztere Variante ist zu gefährlich weil keiner weiß wie viele Sessions der Hoster zur Verfügung stehen hat. Und nicht jeder stinknormale Homepagebastler leistet sich seinen eigenen Root/Managed-Server für geschätzt 100€ im Monat

Lehrbuch schön und gut, aber es gibt auch Grenzen!

VlG

[volkard]

RandomAccess85 schrieb:

Hallo,

es ist doch abartig wie ihr immer auf Lehrbuchwissen und Lehrbuchmethoden zurückgreift

Folgende Variante zum Erstellen einer SessionID...

srand(microtime()*1000000);
$zufall = rand(1,1000000);
$zufall=$zufall.$VielleichtNochDerNutzername; //Oder eben der aktuelle Timestamp
// Kann auch $zufall = session_id().$timestamp; sein
$session = MD5($zufall);

ist in etwa gleichzusetzen mit

session_start();
session_id();

Kannst Du dafür einen Nachweis erbringen, indem Du Code heranbringst, wie PHP das innendrin macht?

[volkard]

RandomAccess85 schrieb:

seinen eigenen Root/Managed-Server für geschätzt 100€ im Monat

Kannst Du Dich nochmal über die Preise informieren, und wenn Du bei unter 50€ für einen dedicated und unter 10€ für einen vServer bist? Was soll der Managed-Server bringen, außer daß der Manager PHP-Sachen konfiguriert, ohne daß ich es mitkriege.

[nman]

RandomAccess85: Für gewöhnlich ist es eine gute Idee, kurz darüber nachzudenken, was Shade und volkard zu sagen haben. Wenn beide an einem Strang ziehen, erst recht. Und in diesem Fall ist das Vorgehen von Shade weithin anerkannte "best practice", dementsprechend wäre es günstiger, Du würdest erläutern, warum Du Dich vor nicht eindeutigen Session-IDs fürchtest.

[Sqwan]

die session_ids sind doch eindeutig. Jedenfalls werden sie nicht extrem eindeutiger nur weil man nen timestamp anhängt.

Und den ganzen sch*** dann jedes mal mit der Datenbank abgleichen zu müssen stelle ich mir jetzt auch nicht sonderlich performant vor

[volkard]

Wenn der Webspace-Provider den temp-Speicherplatz so runtergedreht hat, daß Sessions frühzeitig sterben, dann muß man sich mit dem mal unterhalten. Er fängt sich doch bloß damit ein, daß die Kunden ihre Sessions alle in die Datenbank verlagern und die Daten trotzdem auf der Platte landen, dafür aber mehr Rechenpower gebraucht wird. Und das wollen wir doch alle nicht.

Sqwan schrieb:

Und den ganzen sch*** dann jedes mal mit der Datenbank abgleichen zu müssen stelle ich mir jetzt auch nicht sonderlich performant vor

Och, wenn man wie in einem Forum eh die Datenbank aufmacht, ist das schon ok. Mit http://www.dynamic-webpages.de/php/function.session-set-save-handler.php geht es angeblich auch wunderbar, statt der normalen Dateien mysql-Zeilen darunterzulegen.
Alles Sessions-Zeug selber nachprogrammieren würde ich aber nicht. Die schlauen Sachen von PHP, wie auf die IP achten oder auf den HOST, dem der Proxy die Daten weitergibt, bei abgeschalteten Cookies automatisch auf die URL ausweichen und so Krimskrams, auch auf dem aktuellen Stand bleiben, was mit inkompatiblen Browsern Sache ist, das wäre mir nix.

Sqwan schrieb:

die session_ids sind doch eindeutig. Jedenfalls werden sie nicht extrem eindeutiger nur weil man nen timestamp anhängt.

Jup.

RandomAccess85 scheint zu denken, wenn der Hoster an der Schraube dreht und nur 1000 gleichzeitige Sessions zuläßt, daß dann auch der Schlüsselraum auf 1000 mögliche Schlüssel zusammenfällt.