login

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.

Sqwan

Shade Of Mine schrieb:

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.

Das erklär mir aber bitte mal. Wieso sollte ich auf $_SESSION verzichten. Das interessiert mich doch als Kunde garnicht. Damit kann sich der hoster rumschlagen. Wenn der Hoster mir die sessions nicht iwie ganz verbietet, dann kann ich sie auch nutzen.
Also als nutzer interessiert mich sowas an für sich garnichts. Egal ob ich ein "normaler Programmierer" bin oder eben nicht. Was auch immer jetzt ein unnormaler ist.

Shade Of Mine

Sqwan schrieb:

Das erklär mir aber bitte mal. Wieso sollte ich auf $_SESSION verzichten. Das interessiert mich doch als Kunde garnicht. Damit kann sich der hoster rumschlagen. Wenn der Hoster mir die sessions nicht iwie ganz verbietet, dann kann ich sie auch nutzen.
Also als nutzer interessiert mich sowas an für sich garnichts. Egal ob ich ein "normaler Programmierer" bin oder eben nicht. Was auch immer jetzt ein unnormaler ist.

Sollst du ja eben nicht, das sage ich ja die ganze Zeit. Ich wiederhole mich hier scheinbar nur... Ich sage die ganze Zeit: PHP Session Management benutzen!

Es gibt lediglich eine Situation wo es Sinn machen kann auf $_SESSION zu verzichten. Und das ist so eine spezielle Situation dass wir sie eigentlich nicht zu diskutieren brauchen.

Wenn du nämlich einen eigenen Cluster hast, hast du ja das Problem dass du die Session Daten nicht lokal auf dem Server speichern kannst. Da HTTP nämlich Stateless ist, ist nicht garantiert dass der User wieder auf diesem Server landet.

Wenn du die Daten nun zwischen allen Servern sharen musst dann brauchst du teilweise einfach Custom Lösungen. Je nachdem wie die Struktur aussieht und was du technisch machen kannst. Hier kann es sein dass du an die Grenzen des PHP Session Management stößt. idR sollte sich das zwar mit einer eigenen PHP Extension lösen lassen, aber uU ist dann dennoch sinnvoller das Management selber zu schreiben.

Aber wie gesagt: das sind so spezielle Situationen dass wir hier eben nicht darüber reden sollten. Denn die wenigsten Leute werden je in so eine Situation kommen.

Mit "normal" meine ich Leute die nicht in solchen extrem Situationen sind.

Shade Of Mine schrieb:

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.

Wer hat was von Cookies gesagt? Wenn ich die Session z.B. in der URL mitschiebe, brauch ich keinen Cookie?! Dann muss ich nur noch in der Datenbank prüfen ob "URL-Session" zu "DB-Session" passt und das wars. Mit Logout, oder nach Timeout wird die Session aus der DB gelöscht (falls die Frage auftaucht)...

Shade Of Mine schrieb:

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.

Um Himmels Willen: Nein! Ich bin jetzt eines Besseren belehrt. Meine Erfahrung gegen dein Wissen. Meine Erfahrung lügt, dein Wissen hat Recht und ich meine Ruhe ;)!

VlG

Shade Of Mine

RandomAccess85 schrieb:

Wer hat was von Cookies gesagt? Wenn ich die Session z.B. in der URL mitschiebe, brauch ich keinen Cookie?! Dann muss ich nur noch in der Datenbank prüfen ob "URL-Session" zu "DB-Session" passt und das wars. Mit Logout, oder nach Timeout wird die Session aus der DB gelöscht (falls die Frage auftaucht)...

dh du verwendest nur Sessions per URL Übergabe? Die Risiken kennst du, oder?

Weiters ist das immernoch kein Problem in diesem Szenario da cookie Lifetime und Session Lifetime 2 unterschiedliche Sachen sind. Nur so angemerkt

Du verwendest also das PHP Session Management nur zum generieren der Session ID und sonst zu garnichts? Nichtmal Cookies, transid, etc? Das ist natürlich eine ziemlich schlechte Idee, da du alle Nachteile des PHP Session Managements dadurch übernimmst, nur die Vorteile nicht.

zB lockt PHP die Session Datei wären der Ausführung des Scripts, was zB bei asynchronen Anfragen durchaus merkbar bremst. Auch wenn du nichts in $_SESSION reinschreibst.

Shade Of Mine schrieb:

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.

Um Himmels Willen: Nein! Ich bin jetzt eines Besseren belehrt. Meine Erfahrung gegen dein Wissen. Meine Erfahrung lügt, dein Wissen hat Recht und ich meine Ruhe ;)!

Jedenfalls scheint deine Erfahrung mit Session Management nicht so toll zu sein

Oder hast du auch nur ein einziges Argument das gegen $_SESSION spricht (von meinem extrem Beispiel abgesehen)?

ghostboss

So, ich bins noch mal.

* warum speichere ich keine Daten in $_SESSION und warum konnte ich mich auf $_SESSION nicht verlassen?

-> als ich mit Html...Php programmieren angefangen habe, wollte ich erstmal für kein Server zahlen weil ich Anfänger war und nicht wuste wie weit ich komme (kann man ja nachvollziehen ). Also habe ich auf einem Freehoster (www.funpic.de) meine Html...Php Seiten getestet. Und da habe ich dann ein Clan Seite aufgebaut. Als ich ein Loginsystem machen wollte, hab ich erstmal versucht die Daten in $_SESSION zu speichern. Doch nach paar Minuten (mal 9, mal 15, mal 3) wurde die Session zerstört, oder so, auf jeden Fall war die weg. Also habe ich das so gelöst dass ich die session_id() in die DB und Cookie gespeichert habe.

Jetzt habe ich einen richtigen Server und hab einfach mal mein System übernommen, weil das so gut funktionier hat. Aber wenn ich Zeit habe versuche ich es mit Session .
(wo kann ich denn die Session einstellen? Im Script oder bei Serverkonfigurations Seite?)

Und noch was. Ich nutze die session_id() nur um den User zu identifizieren.

if( cookie(session_id) == DB(session_id) ) user = lars
else user = gast

Ich könnte doch statt session_id irgendwas andres hashen, z.B. md5(user_name) oder md5(timestamp()) (ist nur ein Beispiel). Und schon habe ich auch eine Id die ich in DB und Cookie speichern kann und brauche die ganzen Sachen von Session nicht mehr.

Was spricht denn eigentlich gegen mein Login-System? (DB und Cookie)
* wegen DB verbindung bei jeder Seite um User zu identifizieren? (ein DB connect zuviel)
* unsicher? (wieso)
* Cookie?
* ???

Shade Of Mine

ghostboss schrieb:

Was spricht denn eigentlich gegen mein Login-System? (DB und Cookie)
* wegen DB verbindung bei jeder Seite um User zu identifizieren? (ein DB connect zuviel)
* unsicher? (wieso)
* Cookie?
* ???

Dein Login System waere vermutlich (ich kenne die Details ja nicht) vollkommen OK wenn du nicht session_start() verwenden wuerdest.

Sobald du naemlich session_start() verwendest hast das ganze PHP Session Management aktiviert - ob du es nutzt oder nicht.

zB wenn transid aktiviert ist, wird die Session ID ja ueberall an die URLs drangehaengt und natuerlich wird ein Cookie gesetzt, etc. Da ist ja ein komplexes System im Hintergrund am laufen.

Wenn sich der User ausloggt musst du zB die PHP Session ja auch wieder zerstoeren, sonst bekommt der User beim naechsten Login wieder die selbe Session ID, etc. Und ganz Riskant: PHP koennte eine Session ID generieren die bei dir noch aktiv ist.

Einfach gesagt: du faehrst 2 gleisig. Das gibt diverse Fallstricke die man beachten muss. Und natuerlich gibt es beim Handling der Session wenn man nicht die erprobten Varianten nimmt, auch ein paar Fallstricke.

Daten serialisieren, Transaktionen (User requestet 2 Seiten die Session Daten aendern gleichzeitig), korrektes Session destroy, Garbage Collection, URL rewriting,...

Und natuerlich implementiert man damit Funktioanlitaet die es bereits fehlerfrei gibt. Session Management ist so schon nicht trivial (Session Fixation, Cross Seite Request Forgery,...)

Wenn man natuerlich einen Server hat der die Session Lebenszeit auf 5 Minuten stellt muss man natuerlich etwas anderes machen. Eine Moeglichkeit waere zB session_set_save_handler gewesen.

Bitte nicht falsch verstehen: das ist fuer eine kleine private Seite alles aktzeptabel. Aber wenn das hier mal jemand liest soll er es eben gleich richtig lesen - darum geht es in einem Forum ja.

Shade Of Mine schrieb:

blubb blubb blubb

Willst du mich ärgern ?

Nein ich kenne die Risiken nicht, wenn ich Daten an die URL hänge! Ich kann mir auch keine gravierenden Risiken vorstellen.

Was sollen denn die Risiken sein?
- Daten verfälschen?
- SQL-Injections?
Das sind keine unvorhersehbaren Risiken, die sich nicht kontrollieren lassen!

*********

Nein ich verwende nicht das PHP-Session Management zum generieren einer Session. Ich verwende folgendes um einen Benutzer eindeutig zu machen:

srand(microtime()*1000000);
$zufall = rand(1,1000000);
$zufall=$zufall.$username;
$session = MD5($zufall); //'tschuldigung dass ich die Variable "session" nannte

*********

Was ich gegen $_SESSION habe sagte ich doch bereits. Die ganze Sache ist mir nicht transparent genug und ich habe zuviel Angst dass Sessions verloren gehen. Ich bin halt einfach kein Fan von SESSION, genauso wie andere keine Javascript, oder ASP, oder C++, oder $_SERVER, oder $_GLOBALS - Fans sind

VlG

Shade Of Mine

RandomAccess85 schrieb:

Shade Of Mine schrieb:

blubb blubb blubb

Willst du mich ärgern ?

Nein ich kenne die Risiken nicht, wenn ich Daten an die URL hänge! Ich kann mir auch keine gravierenden Risiken vorstellen.

Was sollen denn die Risiken sein?
- Daten verfälschen?
- SQL-Injections?
Das sind keine unvorhersehbaren Risiken, die sich nicht kontrollieren lassen!

Dachte ich mir dass du sie nicht kennst.
Ein Anfang waere hier zB: http://de.php.net/manual/en/session.security.php
Session Fixation und Session Hijacking/Session Riding sind nur ein paar der Sachen auf die man aufpassen muss. Gibt noch eine Menge andere Gruende die Session ID moeglichst wenig oft anzuzeigen.

Aergern will ich eigentlich Niemanden. Aber ein bisschen etwas lehren, das will ich.

Nein ich verwende nicht das PHP-Session Management zum generieren einer Session. Ich verwende folgendes um einen Benutzer eindeutig zu machen:
srand(microtime()*1000000);
$zufall = rand(1,1000000);
$zufall=$zufall.$username;
$session = MD5($zufall); //'tschuldigung dass ich die Variable "session" nannte

Mal davon abgesehen dass man mt_rand statt rand verwendet und srand unnoetig ist, ja das ist eine schwache Funktion zur Generierung einer Session ID. Bis auf dass du halt keine Kollisionen checkst und die Session ID relativ leicht erratbar ist. Der Username in der Session ID rettet das ganze ein bisschen.

Was ich gegen $_SESSION habe sagte ich doch bereits. Die ganze Sache ist mir nicht transparent genug und ich habe zuviel Angst dass Sessions verloren gehen.

dh du verstehst das System dahinter nicht?
Da kann nichts passieren und die Sessions sind komplett transparent. Ich kann dir zu jedem Zeitpunkt genau sagen in welchem Status die Session ist. Das einzige was vielleicht ein bisschen kompliziert zu verstehen ist, ist die Garbage Collection.

Das ist wie wenn ich sage, ich traue std::sort() nicht, ich sortiere lieber selber... Dein Session ID generieren ist zB ein gutes Beispiel warum man nicht immer das rad neu erfinden sollte, weil fuer bestimmte Probleme haben die Leute schon richtig lange nachgedacht wie das richtig geht.

Ich bin halt einfach kein Fan von SESSION, genauso wie andere keine Javascript, oder ASP, oder C++, oder $_SERVER, oder $_GLOBALS - Fans sind

dh du kannst es nicht Begruenden?

Ich fuer meinen Teil versuche immer das passendste Tool fuer einen Job zu nehmen. Wenn zB bei uns jemand sagen wuerde er traut den PHP Sessions nicht wuerde ich mir ziemlich meine Gedanken machen ob diese Person bei uns richtig ist. Das bitte nicht falsch verstehen, aber ich tu mir gerade echt schwer vorzustellen wir in so einer Situation machen wuerden...

volkard

RandomAccess85 schrieb:

Was ich gegen $_SESSION habe sagte ich doch bereits. Die ganze Sache ist mir nicht transparent genug

Ja, das habe ich auch gelegentlich, wenn ich C++-Libs verwende.

und ich habe zuviel Angst dass Sessions verloren gehen.

Kann ich nicht direkt nachvollziehen. Aber ist auch egal.

RandomAccess85 schrieb:

Ich bin halt einfach kein Fan von SESSION

Das reicht. Ich denke, es wurde jetzt ausreichend oft gesagt, daß SESSION schon was furchtbar Gutes ist. Aber wenn ich ehrlich bin, ich würde es auch nur für Kundenprojekte und alles andere nehmen, aber nicht für mein Steckenpferdprojekt.