login

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

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

[Shade Of Mine]

ghostboss schrieb:

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.

Natuerlich schreibt man die Session ID ins Cookie, das ist ja die Idee warum man ueberhaupt eine Session ID generiert.

Meine Frage war ja: ob du die Session ID selber generierst oder ueber session_start() und dann per session_id() ausliest?

[ghostboss]

Mit session_start() und session_id()

[Shade Of Mine]

ghostboss schrieb:

Mit session_start() und session_id()

Und warum speicherst du die Daten dann nicht in $_SESSION?

Du nimmst mit session_start() alle Nachteile des PHP Session Managements mit, tust aber die Vorteile selber implementieren.

Was genau ist die Idee dahinter $_SESSION nicht zu verwenden? Du sagst du konntest dich auf $_SESSION nicht verlassen, nur faellt mir dazu keine Server Konfiguration ein wo ich das reproduzieren koennte.

Denn wenn $_SESSION vom Server geloescht werden wuerde, dann waere automatisch die Session ungueltig und session_start wuerde eine neue Session ID generieren. Aber gut, wenn es technische Gruende gibt warum das auf einem bestimmten Server nicht klappt...

Ich wuerde dir dennoch empfehlen das Session Management entweder komplett selber zu machen oder komplett PHP zu ueberlassen. Du kannst ueber session_set_save_handler() naemlich auch die Session Daten in eine Datenbank oder sonstwohin speichern.

[RandomAccess85 | offline]

Shade Of Mine schrieb:

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.

Den Vortrag ansich hab ich verstanden. Aber ich habe nicht verstanden wieso du ihn hälst :p

Nur ums klarzustellen:
Ich darf mich Besitzer eines Root-Servers nennen und muss nicht rumfrickeln um eine anständige Session zu Stande zu bekommen. Ich bin mit dem Root-Server aber auch kein Maßstab. Ich gehe von Hobby-Bastlern aus, die eben diese Möglichkeit nicht haben. Und bei "all-inkl" hat man z.B. keine Möglichkeit an den PHP-Ini's zu schrauben. All-inkl selbst sagt sogar aus, dass wen man eine Verbesserung haben möchte, man sich einen Managed-Server zulegen muss (welcher im Monat ab 79€ aufwärts kostet) ...

Was genau ist die Idee dahinter $_SESSION nicht zu verwenden? Du sagst du konntest dich auf $_SESSION nicht verlassen, nur faellt mir dazu keine Server Konfiguration ein wo ich das reproduzieren koennte.

session.cookie_lifetime = 1;
= ziemlicher Blödsinn, könnte aber genau die Situation nachstellen

apache2 reload
= leert soweit ich weiß auch den Session-Cache

apache2 restart
= siehe oben

VlG

[Shade Of Mine]

RandomAccess85 | offline schrieb:

Nur ums klarzustellen:
Ich darf mich Besitzer eines Root-Servers nennen und muss nicht rumfrickeln um eine anständige Session zu Stande zu bekommen. Ich bin mit dem Root-Server aber auch kein Maßstab. Ich gehe von Hobby-Bastlern aus, die eben diese Möglichkeit nicht haben. Und bei "all-inkl" hat man z.B. keine Möglichkeit an den PHP-Ini's zu schrauben. All-inkl selbst sagt sogar aus, dass wen man eine Verbesserung haben möchte, man sich einen Managed-Server zulegen muss (welcher im Monat ab 79€ aufwärts kostet) ...

Für 5 Euro bekommst du alles was du brauchst. Du brauchst für normale Anwendungen keine Änderungen an der php.ini

Du springst von einem extrem ins andere: Rootserver und Freehoster sind 2 extreme die man idR nicht braucht. Wir hosten zB viele Kundenseiten auf all-inkl - ohne Rootserver. php.ini Anpassungen waren noch nie notwendig. Und schon garnicht für so triviale Sachen wie eine Session.

session.cookie_lifetime = 1;
= ziemlicher Blödsinn, könnte aber genau die Situation nachstellen

Nope, stellt die Situation nicht nach, da die Session ID verloren geht und somit das Speichern in der DB nichts bringt da bei einem neuen Request des Users keine Session ID mitgesendet wird.

apache2 reload
= leert soweit ich weiß auch den Session-Cache

Nope.

apache2 restart
= siehe oben

Nope.