login

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.

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

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

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.

@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.~

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.

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.

Shade Of Mine

RandomAccess85 schrieb:

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

Das hat nichts mit Lehrbuchwissen zu tun. Das ist Erfahrung.
Nicht falsch verstehen bitte, aber gerade so Sachen wie Sicherheit (und Session Managemengt ist ein wichtiger Teil der Sicherheit) sind mir sehr wichtig. Da es hier enorm viel schlechten Code gibt. Ein Beispiel ist zB deine Art der Session ID generierung. Das ist unsicher.

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

Tut mir leid ich habe nie Freehoster benutzt. Aber das sollte hier irrelevant sein, denn wenn man sich eben keine 2-3 Euro im Monat leisten kann, dann ist das ein anderes Thema. Ich rede hier davon wie man es richtig macht.

Klar, wenn man keine Infrastruktur hat die etwas taugt, muss man ziemlich bloede Workarounds machen - aber diese Workarounds haben hier nichts verloren.

Wenn du einen bestimmten Workaround auf einem bestimmten Server benutzen musst, ist das deine Sache. Aber um ehrlich zu sein, 2-3 Euro im Monat sollte schon drinnen sein. Du brauchst keinen root Server, Managed Server oder sonstwas, sondern bei all-inkl.com kostet der billigste Webspace 4.95 Euro im Monat. 1GB Speicherplatz, PHP, Perl, MySQL,... und all-inkl ist relativ teuer. Fuer 5 Euro bekommt man mehr als man braucht, wenn man etwas sucht findet man billigere Hoster die halt nicht so gut sind. 1-2 Euro kostet zB Webspace ohne PHP Support. Und in den Preisen ist sogar noch eine Domain drinnen.

Und um ehrlich zu sein: ein Freehoster garantiert keine erreichbarkeit, da wuerde ich lieber selber zu hause hosten...

@ghostboss:
Das verstehe ich nicht. Wenn die Session stribt, also die Session ID ungueltig wird, dann erkennt PHP es daran dass die relevante Datei geloescht wird. Ob du nun etwas in $_SESSION speicherst oder nicht. Oder meinst du, dass du die Session ID nur von PHP generieren hast lassen und ansonsten ein eigenes Session Management implementiert hast?

ghostboss

@Shade Of Mine:
Ich generiere die Session_id nur um den User zu identifizieren. Wenn der User sich Einloggt, dan erstelle ich die Session_id und speichre sie in DB und Cookie.
Ich könnte auch die Id des User im Cookie speichern, aber dann könnte "man" ja selber ein Cookie erstellen (ka ob das geht) und "irgendeine" Id rein schreiben, und schon ist man Admin.
Und mit Session_id geht das nicht so leicht.

Sonst hab ich kein Management.