Frage bzgl. PHP-Sessions Cookies und TransURL



  • Hallo alle zusammen 🙂

    Ich habe ein Skript was folgendes am Anfang tut:

    ini_set ( "session.use_only_cookies", "1" );
    ini_set ( "session.cookie_httponly", "1" );
    ini_set ( "session.use_trans_sid", "0" );
    

    Danach wird $_SESSION['name'] auf "NAME" gesetzt und ausgegeben.
    Klicke ich nun auf der Seite auf links etc... wird der Name angezeigt, obwohl ich cookies im Browser deaktiviert habe.

    Liege ich richtig, das PHP die Session auch anhand der IP zuordnen kann? Serverseitig?

    Dann hätte ich noch eine Frage bzgl. geschützter Bereiche oder Logins:
    Was meint ihr ist die beste Methode? Ich mache mir Sorgen wegen AOL Proxys...
    Da wäre doch eine reine Cookie-Lösung die beste oder?
    Sessions über Links zu transferieren ist Müll.

    Gruss BoinK



  • BoinK schrieb:

    Liege ich richtig, das PHP die Session auch anhand der IP zuordnen kann? Serverseitig?

    Nein, du liegst falsch 😉
    Wie genau PHP das handhabt, kann ich dir nicht sagen; ausschließlich anhand der IP wird es aber nicht agieren.

    Abgesehen davon entscheidet PHP afair automatisch, welche Art des Session-Transfers verwendet wird. Erkennt es also, warum auch immer, dass sie per Cookies nicht übertragen werden kann, wird die SID halt an URLs angehängt.

    BoinK schrieb:

    Dann hätte ich noch eine Frage bzgl. geschützter Bereiche oder Logins:
    Was meint ihr ist die beste Methode? Ich mache mir Sorgen wegen AOL Proxys...
    Da wäre doch eine reine Cookie-Lösung die beste oder?

    Meist ein Hybrid aus Cookie/Datenbank. Wobei du im Cookie z.Bsp. verschlüsselt deine Session-ID und noch andere "statuserhaltende" Werte einfügen kannst.

    Im Allgemeinen gilt nur: Verlasse dich niemals auf die IP! Nicht nur AOL-Nutzer bekommen da ein Problem, sondern so ziemlich jeder, der aus dem Internet fliegen kann oder durch die Zwangstrennung des Providers alle 24h eine neue IP zugewiesen bekommt. Sicher, wenn dein Login nur für z.B. 3min läuft, kann man das vernachlässigen ... Aber davon steht hier nichts 😉
    Eine Überprüfung des IP-Subnetzes ist übrigens auch nicht empfehlenswert, entgegen zahlreicher "Tutorials", die es empfehlen; ein Provider kann heutzutage über manche verschiedene Subnets verfügen.



  • Hallo árn[y]ék,

    stimmt, das Leuchtet auch ein mit der IP -.-

    Ichglaube es ist auch besser auf URL-Transfer umzusteigen, wenn keine Cookies möglich sind. Mit den ini settings hätte ich das ja unterdrückt, aber immer noch besser, als keine User 😉

    Ich würde sagen, dass ich für jeden Login alle Datensammle und speicher, die nur gehen, und außerdem, da die Session eh per Browser oder URL übermittelt wird, dürfte das auch kein Problem darstellen, ist mir grade so aufgefallen 🙂

    Also Sub-Netze sind wirklich eine schlechte Idee, da hast Du recht, das Provider unterschiedliche haben können. Ich denke die Hybride Lösung ist am besten. Danke für die Tipps 🙂

    Grüsse


  • Mod

    árn[y]ék schrieb:

    Wie genau PHP das handhabt, kann ich dir nicht sagen; ausschließlich anhand der IP wird es aber nicht agieren.

    php schaut nur auf die session id

    Abgesehen davon entscheidet PHP afair automatisch, welche Art des Session-Transfers verwendet wird. Erkennt es also, warum auch immer, dass sie per Cookies nicht übertragen werden kann, wird die SID halt an URLs angehängt.

    php setzt sowohl das cookie als auch die id in GET/POST und erkennt dann: wenn die session id sowohl über GET/POST und cookie kommt, wird nur noch cookie verwendet.

    Meist ein Hybrid aus Cookie/Datenbank. Wobei du im Cookie z.Bsp. verschlüsselt deine Session-ID und noch andere "statuserhaltende" Werte einfügen kannst.

    session id verschlüsseln bringt nichts.



  • Shade Of Mine schrieb:

    session id verschlüsseln bringt nichts.

    Stimmt, ich meinte eigentlich den Inhalt des Cookies ingesamt, um ihn vor benutzerdefinierten Änderungen zu schützen. Und wenn schon die Session-ID im Cookie gespeichert wird, wird sie halt mitverschlüsselt. Der Schwerpunkt meiner Aussage hatte eigentlich auf dem Speichern der "statuserhaltenden Werte" liegen sollen 😉


Anmelden zum Antworten