login

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

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.

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.

Shade Of Mine schrieb:

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.

Ist toll für dich, bedeutet aber noch lange nicht dass das der Normalzustand ist. Frag mal nach memcache (ebenso trivial wie Sessions) bei all-inkl...

Shade Of Mine schrieb:

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.

Deswegen steht sie doch in der DB => damit sie eben nicht verloren geht...
Es geht hier immernoch um einen Login und lediglich um eine SessionID, NICHT um Session-Daten! Was bedeutet, dass sie einmal vergeben wird und danach nur noch der Identifizierung nützt.

Shade Of Mine schrieb:

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

Nope.

Zitat:
apache2 restart
= siehe oben

Nope.

Ok, da hab ich mich getäuscht. Ich bin davon ausgegangen, dass zumindest der Restart sämtliche Prozesse killt und die Sessions als "Garbage-Data" weiter behandelt werden, die gemäß Standardkonfiguration nach 3 Minuten entsorgt werden.

VlG

P.S. Im Offline-Post gingen die Quotes etwas daneben. Könnte den bitte einer löschen? Danke!

Shade Of Mine

RandomAccess85 schrieb:

Ist toll für dich, bedeutet aber noch lange nicht dass das der Normalzustand ist. Frag mal nach memcache (ebenso trivial wie Sessions) bei all-inkl...

Birnen und Äpfel.

Aber bitte, dann geh auf einen anderen Hoster. memcache ist bei einem 5 Euro Host aber komplett irrelevant. memcache brauchst du nur aus Performance Gründen die bei 5 Euro egal sind. Geld sollte also wirklich keine Rolle spielen. Wenn man kein Geld hat nimmt man einen billigen Hoster und verzichtet auf advanced Features, wenn man mehr Geld hat bekommt man auch diese Features dazu.

Das ist aber alles nicht Thema. Denn Sessions funktionieren immer.

Shade Of Mine schrieb:

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.

Deswegen steht sie doch in der DB => damit sie eben nicht verloren geht...
Es geht hier immernoch um einen Login und lediglich um eine SessionID, NICHT um Session-Daten! Was bedeutet, dass sie einmal vergeben wird und danach nur noch der Identifizierung nützt.

Wenn die lifetime des Cookies zu niedrig steht, dann wird bei dem nächsten Request des Users die Session ID aber nicht mitgesendet weil das Cookie ausgetimt ist. dh du hast auf der Serverseite keine Ahnung mehr welche Session ID dieser User hat. Ergo ist es egal wo du die Daten gespeichert hast: du hast die Session ID verloren und damit die Daten.

Ich bin davon ausgegangen, dass zumindest der Restart sämtliche Prozesse killt und die Sessions als "Garbage-Data" weiter behandelt werden, die gemäß Standardkonfiguration nach 3 Minuten entsorgt werden.

Die Session Daten liegen in einem temp Verzeichnis als einfache Dateien. Du musst schon den kompletten Server neustarten um eventuell das Verzeichnis zu killen. Ansonsten kannst du natürlich die Daten auch in einer Datenbank oder ähnliches stehen haben. Standard bei PHP sind halt Dateien in einem temp Verzeichnis, lässt sich aber alles konfigurieren.

Kann es sein dass du krampfhaft versuchst Gründe zu finden warum du nicht $_SESSION verwenden willst? Da kann ich dir helfen: es gibt genau einen relevanten Grund: Performance auf Clustern. Aber da gehen wir jetzt erstmal nicht näher ein, da das für einen normalen Programmierer irrelevant ist, da die meisten Leute nie in so eine Situation kommen werden.

PS:
und selbst in so einer Situation könnte man die Standard PHP Sessions verwenden mit einer eigenen PHP Extension.