login

[ghostboss]

Hallo,

ich mache das so:

* User gibt seine Daten ein (Name, Passwort)
* Script sucht in der Datenbank nach Namen
* Wenn Name gefunden dann wird Passwort vergliechen (mit md5())
* Wenn Passwort passt dann speichert Script die Session_id() im Cookie und in der Datenbank

Und dann auf jeder Seite einfach die Session_id() vom Cookie abfragen und mit den Session_id()'s in der Datenbank vergleichen, wenn eine Session_id() passt dan hast du den User.

Ach, und das Cookie speichere ich nur für die eine Sitzung (so langen der Browser an ist), natürlich kann man das auch für länger speichern.

(natürlich speichere ich nicht nur die Session_id() sondern noch etwas)

Mit $_SESSION[] mach ich das nicht, weil ich mal einen Freehoster hatte (funpic) und da wurde die $_SESSION[] nicht lange gespeichert (mal 15 Min., mal 3 Min., mal 9 Min.), der User wurde also nach 9 Min. oder so ausgeloggt.
Wie das bei Normalhoster (also wo man bezahlen muss) ist weiß ich nicht. Ich könnte das zwar ausprobieren aber dann müsste ich einiges auf meiner Homepage ändern, ausserdem bin ich mit Cookies zufrieden :).

[Shade Of Mine]

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).

[zuuuuu]

http://www.php-einfach.de/php-tutorial/php-sessions.php

[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.