Session ohne Cookies: browser-cache-Problem?

[AirMax]

Hallo selfhtml-ler,

Ich habe schon ein bisschen gegoogelt & bin mir nicht sicher, ob ich einen Fehler mache oder ob es wirklich ein browser-cache-Problem ist. Falls das Thema schon einmal diskutiert wurde, wäre ich Euch über Hinweise/Links dankbar!

Also, meine Frage dreht sich um Sessions:
Ich habe einen Login-Bereich erstellt. Funktioniert alles auch wunderbar: Falls Cookies aktiviert sind, wird die Session (und alle damit assoziierten Variablen) beim Logout gelöscht. Ein Klick auf den "browser-zurück-Pfeil" leitet mich dann auf die 'login.php' - so soll es sein.
Das Problem taucht auf, wenn Cookies deaktiviert sind: Ich übergebe die SID nur ein einziges Mal - und zwar dann, wenn ich bei einer korrekten Eingabe der user-Daten auf die entsprechende Folgeseite leite (mehr ist für meine Ansprüch auch nicht nötig). Wenn ich allerdings zu einem späteren Zeitpunkt per "browser-zurück-Pfeil" in den geschützten Bereich zurückgehe, bekomme ich ungehindert Zugang. Genau das kann ich aber irgendwie nicht nachvollziehen. Eigentlich sollte die Verbindung zur noch gültigen Session schon längst abgebrochen sein. Liegt es daran, das der Browser die Seiten cached oder daran, dass ich einen Fehler mache? Ich hoffe, Ihr konntet halbwegs nachvollziehen, was ich meine.

Wäre über Eure Hilfe dankbar!

Gruß
AirMax

[Prof. Sakkkkarre]

Zwei bemerkungen:

• die Session ID kann als Cookie gehalten, und per POST von Client zum Server gesendet werden. Du kannst aber auch die SID per GET (als mit "Fragenzeichenparameter" hinter der URI) zum Server schicken. Cookies sind also mehr oder weniger belangslos.

• Am wichtigsten ist, am Ende einer Session diese auf _explizit_ zu beenden!!!!!!

[AirMax]

Hi Prof. Sakkkkarre

• die Session ID kann als Cookie gehalten, und per POST von Client zum
  Server gesendet werden. Du kannst aber auch die SID per GET (als mit
  "Fragenzeichenparameter" hinter der URI) zum Server schicken.

Ja genau, so mache ich es: Je nachdem, ob das Session-Cookie gesetzt werden konnte leite ich per location-header mit 2 Varianten "weiter".

Variante 1:

// Cookie konnte gesetzt werden  
header('location:' . $_SERVER['HTTP_REFERER']);

Variante 2:

// Cookie konnte nicht gesetzt werden  
header('location:' . $_SERVER['HTTP_REFERER'] . '?' . SID);

• Am wichtigsten ist, am Ende einer Session diese auf _explizit_ zu beenden!!!!!!

Du meinst also, ich soll auch nochmal (für den Fall, dass keine Cookies gespeichert werden können) die SID vom "geschützten Bereich" zur 'logout.php' per GET übergeben, damit die Session auch ordentlich abgeschlossen werden kann? Ist das mein Fehler?

Gruß

[ChrisB]

Hi,

Du meinst also, ich soll auch nochmal (für den Fall, dass keine Cookies gespeichert werden können) die SID vom "geschützten Bereich" zur 'logout.php' per GET übergeben, damit die Session auch ordentlich abgeschlossen werden kann? Ist das mein Fehler?

Wenn du die SID dorthin *nicht* übergibst, dann wird das dort (vermutlich) stehende session_start natürlich eine neue Session starten. In der kannst du den Nutzer so oft, so lange und so gründlich als ausgeloggt kennzeichnen, wie du lustig bist - das wird den Zustand der anderen Session kein bisschen verändern.

MfG ChrisB

[AirMax]

Hi ChrisB,

Wenn du die SID dorthin *nicht* übergibst, dann wird das dort (vermutlich) stehende session_start natürlich eine neue Session starten. In der kannst du den Nutzer so oft, so lange und so gründlich als ausgeloggt kennzeichnen, wie du lustig bist - das wird den Zustand der anderen Session kein bisschen verändern.

Ich ging immer davon aus, dass die Session "für immer verloren ist", sobald die SID an einer Stelle NICHT per GET übergeben wird und die Kette quasi wie unterbrochen ist. Dass also

  
if (  
  isset($_SESSION['userid'])  
    ) {  
    ...............  
      }

in diesem Fall FALSE ist.

[Prof. Sakkkkarre]

Ich ging immer davon aus, dass die Session "für immer verloren ist", sobald die SID an einer Stelle NICHT per GET übergeben wird und die Kette quasi wie unterbrochen ist. Dass also

Eine Session ist dann unwiederbringlich beendet, wenn auf dem Server
die Session Daten (meist ein File; bei eigenem Handlich auch eine
Datenbank) gelöscht sind!!!!!!!!!

[AirMax]

Eine Session ist dann unwiederbringlich beendet, wenn auf dem Server
die Session Daten (meist ein File; bei eigenem Handlich auch eine
Datenbank) gelöscht sind!!!!!!!!!

Ich probier es mal aus. Wenn es nicht klappt, melde ich mich wieder.
Danke an euch beide!

Gruß

[Prof. Sakkkkarre]

Ich probier es mal aus. Wenn es nicht klappt, melde ich mich wieder.
Danke an euch beide!

Ich bin aber eine Eintagsfliege (ich kann das Aufatmen förmlich höfen).
Aber "wenn ich nicht mehr bin" gibts ja hier auch viele andere ganz
Schlaue ...

[AirMax]

Ich bin aber eine Eintagsfliege (ich kann das Aufatmen förmlich höfen).
Aber "wenn ich nicht mehr bin" gibts ja hier auch viele andere ganz
Schlaue ...

Was soll das heißen? Entweder Du willst mich veräppeln oder das ist Dein Ernst. Falls es Dein Ernst sein sollte, musst Du mir Deine Aussage noch ein bisschen genauer erklären!

[Prof. Sakkkkarre]

Ich bin aber eine Eintagsfliege (ich kann das Aufatmen förmlich höfen).
Aber "wenn ich nicht mehr bin" gibts ja hier auch viele andere ganz
Schlaue ...

Was soll das heißen? Entweder Du willst mich veräppeln oder das ist Dein

Ernst. Falls es Dein Ernst sein sollte, musst Du mir Deine Aussage noch ein bisschen genauer erklären!

Da gibts nicht viel zu erklären. Ich schreibe Anonym und mache es nur
mal so hin und wieder. Bei Wiki arbeite ich z.B. nur als IP - das ist
schwer aber mir ist Anonymität heilig ... Jeder hat seine Macke ...

Und wenn morgen eine Schneewanderung angesagt ist, dann bin ich mit
sehr viel Enthusiasmus nicht merhr hier ... Tschau

[AirMax]

Da gibts nicht viel zu erklären. Ich schreibe Anonym

Das tun die meisten hier!

[...] mir ist Anonymität heilig.

Das kann ich vollkommen nachvollziehen.

Und wenn morgen eine Schneewanderung angesagt ist, dann bin ich mit
sehr viel Enthusiasmus nicht merhr hier [...]

Das kann ich ebenfalls verstehen. Es gibt nichts schöneres als bei diesem Winter auf's board zu steigen!

In diesem Sinne: Gute Nacht

[Prof. Sakkkkarre]

• Am wichtigsten ist, am Ende einer Session diese auf _explizit_ zu beenden!!!!!!
  Du meinst also, ich soll auch nochmal (für den Fall, dass keine Cookies gespeichert werden können) die SID vom "geschützten Bereich" zur 'logout.php' per GET übergeben, damit die Session auch ordentlich abgeschlossen werden kann? Ist das mein Fehler?

Nein, ich meine ganz simpel das Pendant zu session_start() - also
session_stop() (oder so ähnlich - habe jetzt keine Lust im Doku
nachzuschauen).

Im Normalfall (du kannst das gesamte Session Handling aber auch selbst übernehmen - siehe Handbuch) werden die Session Daten in irgendeinen
Session File als serialisierte Daten gespeichert. Diese Datei sollte
weg! Das erledigst du mit session_stop() - und dies sollte in der
logout Routine stehen ...

Dann gibts da noch den Fall, das sich jemand nich abmeldet. Das
Session System von PHP hat das ein Aufräumssystem vorgesehen (bei
JEDEM session_start() (also auch von "Nachbarprogrammen") wird im
dem Direktory, in dem die Session Dateien liegen, nach alten Session
Files geguckt und diese gelöscht (auch dieses Handling - sesson_garbage()
oder so ähnlich, kannst du selbst übernehmen).

Kurz und gut die einfachste Lösung ohne das Session Handling zu
verbiegen:

Beim erfolgreichen Login erzeugst du zwei Session Vars:

§_SESSION[login_korrekt]=boolean
  §_SESSION[letzter_kontakt]=timstamp

Die Variable §_SESSION[letzter_kontakt] setzt du bei JEDEM Seitenaufruf
neu. VORHER prüfst du aber, ob $aktuelle_zeit minus §_SESSION[letzter_kontakt] eine von dir vorgegebene Zeit überschreitet.
Klar, das bei Zeitüberschreitung der Benutzer abgewiesen und die
Session dann gelöchst werden muss (session_stop() reicht da aus).

Warum ist das mit der Zeitüberschreitung wichtig? Das PHP System
zum löschen der alten Sessions ist von einigen Zufallsfaktoren
abhängig. Im Prinzip kann eine Session ewig leben wenn sie nicht
gelöscht wird ... und aus reiner Vorsicht ist es daher zu empfehlen,
in den Session Daten den Zeitpunkt der letzen Aktivität zu merken.

So long

[AirMax]

Nein, ich meine ganz simpel das Pendant zu session_start() - also
session_stop() (oder so ähnlich - habe jetzt keine Lust im Doku
nachzuschauen).

session_destroy();

Warum ist das mit der Zeitüberschreitung wichtig? Das PHP System
zum löschen der alten Sessions ist von einigen Zufallsfaktoren
abhängig. Im Prinzip kann eine Session ewig leben wenn sie nicht
gelöscht wird ... und aus reiner Vorsicht ist es daher zu empfehlen,
in den Session Daten den Zeitpunkt der letzen Aktivität zu merken.

Laut 'php.ini' ist die Session-lifetime 3600 Sekunden. Danach ist sie zum Abschuss automatisch freigegeben. Einfluss auf die 'php.ini' habe ich leider nicht! *schnief*

Gruß

[Prof. Sakkkkarre]

Nein, ich meine ganz simpel das Pendant zu session_start() - also
session_stop() (oder so ähnlich - habe jetzt keine Lust im Doku
nachzuschauen).
session_destroy();

Ja, so heisst das Ding - sorry. Aber die Funktion wird normalerweise nur
indirekt aufgerufen. Wenn nach einer Session auf einem wenig benutzen
Server keine weiteren session_start() oder session_stop() aufgerufen
werden, lebt das Session File weiter ...

Warum ist das mit der Zeitüberschreitung wichtig? Das PHP System
zum löschen der alten Sessions ist von einigen Zufallsfaktoren
abhängig. Im Prinzip kann eine Session ewig leben wenn sie nicht
gelöscht wird ... und aus reiner Vorsicht ist es daher zu empfehlen,
in den Session Daten den Zeitpunkt der letzen Aktivität zu merken.
Laut 'php.ini' ist die Session-lifetime 3600 Sekunden. Danach ist sie zum Abschuss automatisch freigegeben. Einfluss auf die 'php.ini' habe ich leider nicht! *schnief*

Sie lieber froh, dass du die Verantwortung nicht trägst :-)
Session-lifetime könnt auch auf 360.000 Sek. stehen. Deshalb ist
eine §_SESSION[LETZER_KONTAKT]=timestamp wichtig!

[AirMax]

Sie lieber froh, dass du die Verantwortung nicht trägst :-)
Session-lifetime könnt auch auf 360.000 Sek. stehen. Deshalb ist
eine §_SESSION[LETZER_KONTAKT]=timestamp wichtig!

Danke für den Tipp. Könnte an geeigneter Stelle mal wichtig werden!
Habe jetzt übrigens mal die SID bis zum logout übergeben. Jetzt ist die Session auch gelöscht und das Login-Formular erscheint, sobald ich auf den "zur vorherigen Seite"-Pfeil im browser klicke!

Danke & Gruß

[dedlfix]

Hi!

Laut 'php.ini' ist die Session-lifetime 3600 Sekunden. Danach ist sie zum Abschuss automatisch freigegeben. Einfluss auf die 'php.ini' habe ich leider nicht! *schnief*

Alle session-spezifischen Konfigurationswerte lassen sich auch im Script noch ändern (Changeable = PHP_INI_ALL). Für manche gibt es eine eigenen Funktion, ansonsten gibt es noch ini_set().

Lo!

[AirMax]

Hi Lo,

session-spezifischen Konfigurationswerte lassen sich auch im Script noch ändern (Changeable = PHP_INI_ALL). Für manche gibt es eine eigenen Funktion, ansonsten gibt es noch ini_set().

Das habe ich auch schon probiert. Sogar beide Varianten: z.B.
session_save_path() und
ini_set(session.save_path)
Nichts zu machen!

Gruß

[dedlfix]

Hi!

Das habe ich auch schon probiert. Sogar beide Varianten: z.B.
session_save_path() und
ini_set(session.save_path)
Nichts zu machen!

Mit "nichts zu machen" ist nichts zu machen. Bitte beobachte und beschreibe genauer! Du hast hoffentlich auch dem PHP/Webserver die Berechtigung zum Schreiben in das angegebene Verzeichnis gegeben?

Lo!

[AirMax]

Hi Lo!

Mit "nichts zu machen" ist nichts zu machen. Bitte beobachte und beschreibe genauer! Du hast hoffentlich auch dem PHP/Webserver die Berechtigung zum Schreiben in das angegebene Verzeichnis gegeben?

Wenn ich lokal teste, kann ich den session_save_path z.B. individuell anpassen. Wenn ich aber auf dem shared server beim provider teste, lässt PHP meine session_save_path-Angabe absolut kalt. Die wird schlicht weg ignoriert. Habe schon mit dem provider gesprochen. Er könne mir keinen Zugriff gewähren...

Gruß

[dedlfix]

Hi!

Wenn ich lokal teste, kann ich den session_save_path z.B. individuell anpassen. Wenn ich aber auf dem shared server beim provider teste, lässt PHP meine session_save_path-Angabe absolut kalt. Die wird schlicht weg ignoriert. Habe schon mit dem provider gesprochen. Er könne mir keinen Zugriff gewähren...

Bleibt nach einer Änderung von session.save_path (mit Punkt) mit ini_set() oder einem Aufruf von session_save_path() die Anzeige in der phpinfo() unverändert oder gibt es eine Meldung à la:

Warning: ini_set()/session_save_path() has been disabled for security reasons

Steht überhaupt etwas in disable_functions? Ist in open_basedir etwas eingestellt, ist der safe_mode ein/ausgeschaltet?

Wie ist der session.save_path überhaupt konfiguriert? Zeigt er auf ein allgemeines Verzeichnis oder ein dir individuell zugeordnetes? In letzterem Fall hättest du nur ein Problem mit mehreren Anwendungen in deinem Paket, wenn sie unterschiedliche Garbage-Collection-Einstellungen benötigen. (Und natürlich das Sicherheitsproblem, wenn die eine Anwendung die Sessiondaten der anderen auslesen kann.)

Lo!

[AirMax]

Hi Lo!

Bleibt nach einer Änderung von session.save_path (mit Punkt) mit ini_set() oder einem Aufruf von session_save_path() die Anzeige in der phpinfo() unverändert [...]

Nein, bleibt unverändert. Keine Fehlermeldung. Ich habe festgestellt, dass ich auf einige ini-Direktiven Einfluss nehmen kann. z.B. session.cookie_path oder session.name. Bei anderen wiederum klappt das nicht. Aber ich bin auch nicht unbedingt scharf drauf den session.save_path zu verändern.

Hier mal die Angaben:

disable_functions:
system,shell_exec,passthru,exec,popen,proc_open,pcntl_exec

open_basedir:
/home/sites/home/:/tmp/:/usr/share/pear/

safe_mode:
Off

session.save_path:
no value

Gruß

[AirMax]

Hallo zusammen

Login ist fertig. Jetzt gibt es noch einen kleinen Schönheitsfehler. Bevor ich zu den Details komme, muss ich noch erwähnen, dass mir wichtig war, dass ich nicht erst im 'geschützten Bereich' auf einen bestimmten Session-Parameter hin überprüfe, sondern schon vor dem Login-Formular. Zum einen erspare ich mir das ständige Angemelde innerhalb einer Session und zum anderen das Gehopse in der URL durch location-header. Meine Struktur sieht deshalb so aus:

|---------------------------------|
                                     V                                 |
                                                                       |
                            SESSIONPARAMETER-CHECK                     |
                            Sessionparameter ok?                       |
                                                                       |
                                     |                                 |
                  |--------------------------------------|             |
                  V                                      V             |
                 ja                                    nein            |
                  |                                      |             |
                  V                                      V             |
        'geschützter Bereich.php'          'login-Formular.php'        |
         einbinden                         einbinden                   |
                                                         |             |
                                                         |-------------|

Um die URL schön übersichtlich zu behalten überprüfe ich vor jedem Request, ob das Session-Cookie gespeichert werden konnte. Je nachdem hänge ich dann die SID an die URL manuell an oder nicht. Soweit so gut. Wenn das Login-Formular zum ersten mal aufgerufen wird, wird das Session-Cookie gespeichert. Bei der ersten Ausgabe des Formulars wird jedoch IMMER (ob mit oder ohne Cookie-Unterstützung spielt keine Rolle) die SID an die URL gehängt, da das Cookie noch nicht an den Server geschickt wurde. Bei der erneuten Ausgabe des Formulars taucht die SID dann nicht mehr in der URL auf.
Jetzt meine Frage: Gibt es eine Lösung, wie ich die SID (und das dazugehörige '?') aus der URL verbannen kann, ohne dass die Funktionalität bei deaktivierten Cookies leidet?

Danke für Eure Hilfe

Gruß

[ChrisB]

Hi,

Um die URL schön übersichtlich zu behalten überprüfe ich vor jedem Request, ob das Session-Cookie gespeichert werden konnte.

Wie soll das gehen - vorher?

Wenn das Login-Formular zum ersten mal aufgerufen wird, wird das Session-Cookie gespeichert.

Wie - ich denke, du nutzt die Sessions vorher schon?

Bei der ersten Ausgabe des Formulars wird jedoch IMMER (ob mit oder ohne Cookie-Unterstützung spielt keine Rolle) die SID an die URL gehängt, da das Cookie noch nicht an den Server geschickt wurde. Bei der erneuten Ausgabe des Formulars taucht die SID dann nicht mehr in der URL auf.
Jetzt meine Frage: Gibt es eine Lösung, wie ich die SID (und das dazugehörige '?') aus der URL verbannen kann, ohne dass die Funktionalität bei deaktivierten Cookies leidet?

So lange du nicht weisst, ob der Client Cookies akzeptiert, gibt es keine andere Möglichkeit als GET oder POST, um die Session-ID zu übergeben.

MfG ChrisB

[AirMax]

Hi ChrisB

hier mal ein bisschen was handfestes:

'login.php'

  
<?php  
session_start();  
if (  
   isset($_SESSION['userid'])  
   ) {  
   include 'logged.inc.php';  
     }  
else {  
   include 'loginform.inc.php';  
     }  
?>

'loginform.php'

  
<form id="login" action="<?php if (isset($_COOKIE['login'])) {echo $_SERVER['PHP_SELF'];} else {echo $_SERVER['PHP_SELF'] . '?' . SID;} ?>" method="post">

Beim ersten Aufruf des Formulars wird die SID an die URL gehängt. Also: action="/php/login.php?login=blablub"
Deshalb, weil das Cookie noch nicht an den Server geschickt wurde. Beim nächsten Request (z.B. falls falsche Zugangsdaten eingegeben wurde) wird das Formular ohne SID verschickt. Also: action="/php/login.php" Und zwar unabhängig davon, ob der Client Cookies akzeptiert oder nicht.

[ChrisB]

Hi,

Beim ersten Aufruf des Formulars wird die SID an die URL gehängt. Also: action="/php/login.php?login=blablub"
Deshalb, weil das Cookie noch nicht an den Server geschickt wurde.

Warum übergibst du die SID nicht in einem hidden field?

MfG ChrisB

[AirMax]

Warum übergibst du die SID nicht in einem hidden field?

Stimmt, warum eigentlich nicht?! An diese Möglichkeit habe ich überhaupt noch nicht gedacht. Werd's mal probieren.

Danke für den Tipp

Gruß

PS: Glaubst Du, dass das vernünftig ist, was ich da mit dem login angestellt habe oder ist das eher umständlich/Unsinn?

[dedlfix]

Hi!

Ich habe festgestellt, dass ich auf einige ini-Direktiven Einfluss nehmen kann. z.B. session.cookie_path oder session.name.

Die beeinflussen das Verhalten in Richtung Client, nicht wie session.save_path das Server-System. Das stört also den Hoster nicht, weswegen er dir das problemlos gestatten kann.

Bei anderen wiederum klappt das nicht. Aber ich bin auch nicht unbedingt scharf drauf den session.save_path zu verändern.

Sollte man aber auf Mehrnutzersystemen, wenn man nicht möchte, dass einem die anderen Nutzer durch ihre GC-Einstellungen die Sessions früher killen, als einem lieb ist.

open_basedir:
/home/sites/home/:/tmp/:/usr/share/pear/

Du hast den session.save_path auch auf (ein Unterverzeichnis) eines dieser Verzeichnisse zeigen lassen?

session.save_path:
no value

Das PHP-Handbuch sagt nicht, wo die Sessiondateien dann abgelegt werden. Und ich finde immer nur Reports, die von Fehlern berichten, wenn session.save_path leer ist.

Lo!

[AirMax]

Hi Lo!

Die beeinflussen das Verhalten in Richtung Client, nicht wie session.save_path das Server-System. Das stört also den Hoster nicht, weswegen er dir das problemlos gestatten kann.

Das wusste ich nicht. Anfängerdummheit!

Bei anderen wiederum klappt das nicht. Aber ich bin auch nicht unbedingt scharf drauf den session.save_path zu verändern.

Sollte man aber auf Mehrnutzersystemen, wenn man nicht möchte, dass einem die anderen Nutzer durch ihre GC-Einstellungen die Sessions früher killen, als einem lieb ist.

Ja, ich weiß. Aber wie gesagt habe ich darauf keinen Einfluss. Ich wüsste ehrlich gesagt auch gar nicht, welches Verzeichnis sich dafür anböte. Mein web-Verzeichnis wohl kaum, oder?

open_basedir:
/home/sites/home/:/tmp/:/usr/share/pear/

Du hast den session.save_path auch auf (ein Unterverzeichnis) eines dieser Verzeichnisse zeigen lassen?

Diese Angabe kommt vom hoster, nicht von mir.

session.save_path:
no value

Das PHP-Handbuch sagt nicht, wo die Sessiondateien dann abgelegt werden. Und ich finde immer nur Reports, die von Fehlern berichten, wenn session.save_path leer ist.

Siehe oben!

Gruß

[dedlfix]

Hi!

Ich wüsste ehrlich gesagt auch gar nicht, welches Verzeichnis sich [für session.save_path] anböte. Mein web-Verzeichnis wohl kaum, oder?

Nein, alles was über HTTP erreichtbar ist, ist noch "tabuer" als ein gemeinsames /tmp.

Ein ordentlicher Provider gestattet, dass man das DocumentRoot auf ein Unterverzeichnis des Kundenverzeichnisses legen kann. So kann man weitere Verzeichnisse anlegen, auf die kein DocumentRoot zeigt, und Dateien ablegen, die nicht (direkt) übers Web zugänglich sein sollen.

open_basedir:
/home/sites/home/:/tmp/:/usr/share/pear/
Du hast den session.save_path auch auf (ein Unterverzeichnis) eines dieser Verzeichnisse zeigen lassen?
Diese Angabe kommt vom hoster, nicht von mir.

Das macht ja nichts. Das sind jedenfalls die Verzeichnisse, auf die du überhaupt mit PHP zugreifen darfst.

Lo!

[Tom]

Hello,

Hier mal die Angaben:

disable_functions:
system,shell_exec,passthru,exec,popen,proc_open,pcntl_exec

open_basedir:
/home/sites/home/:/tmp/:/usr/share/pear/

safe_mode:
Off

session.save_path:
no value

Also default das /tmp/-Verzeichnis

Wenn PHP hier jetzt auch noch als Modul läuft, dann sind die Sessions der anderen User aller Wahrscheinlichkeit nach entführbar.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

hat er überhaupt die richtige php.ini erwischt?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

hat er überhaupt die richtige php.ini erwischt?

Die ist unerreichbar. Deswegen ja auch session_save_path() oder ini_set().

Lo!

[Tom]

Hello,

hat er überhaupt die richtige php.ini erwischt?

Die ist unerreichbar. Deswegen ja auch session_save_path() oder ini_set().

Stimmt auch wieder. Da war ich eben unaufmerksam.

Aber die müssten dann ja, so wie Du schon schreibst, eine Fehlermeldung verursachen, wenn sie irgendwie verboten wären, vorausgesetzt selbstverständlich, dass es sich nicht um eine wild gepatchte PHP-Version handelt.

AirMax sollte aber mal versuchen, das /tmp/-Verzeichnis auszulesen und sich die Anzeige dann (z.B. als Screenshot) zu merken. Sollte er dann tatsächlich Einblick in fremde Sessiondateien nehmen können, wäre das der berühmte Ansatzpunkt für seinen Hebel, den Provider zum Handeln zu bewegen.

Und wenn DER dann immer noch nicht handeln will, dann muss er geächtet und gewechselt werden!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[AirMax]

Hi Tom,

AirMax sollte aber mal versuchen, das /tmp/-Verzeichnis auszulesen und sich die Anzeige dann (z.B. als Screenshot) zu merken. Sollte er dann tatsächlich Einblick in fremde Sessiondateien nehmen können, wäre das der berühmte Ansatzpunkt für seinen Hebel, den Provider zum Handeln zu bewegen.

Das mit dem Auslesen kann ich mal versuchen. Falls das klappen sollte, kann ich ja mal berichten *grinst*

Gruss

[Tom]

Hello AirMax,

Also, meine Frage dreht sich um Sessions:
Ich habe einen Login-Bereich erstellt. Funktioniert alles auch wunderbar: Falls Cookies aktiviert sind, wird die Session (und alle damit assoziierten Variablen) beim Logout gelöscht. Ein Klick auf den "browser-zurück-Pfeil" leitet mich dann auf die 'login.php' - so soll es sein.
Das Problem taucht auf, wenn Cookies deaktiviert sind: Ich übergebe die SID nur ein einziges Mal - und zwar dann, wenn ich bei einer korrekten Eingabe der user-Daten auf die entsprechende Folgeseite leite (mehr ist für meine Ansprüch auch nicht nötig). Wenn ich allerdings zu einem späteren Zeitpunkt per "browser-zurück-Pfeil" in den geschützten Bereich zurückgehe, bekomme ich ungehindert Zugang. Genau das kann ich aber irgendwie nicht nachvollziehen. Eigentlich sollte die Verbindung zur noch gültigen Session schon längst abgebrochen sein. Liegt es daran, das der Browser die Seiten cached oder daran, dass ich einen Fehler mache?

Bei der Fehlersuche in diesem Wechselspiel (Request - Response -Request - Response - usw.) ist es immer ganz hilfreich, sich genaue Übersicht zu verschaffen, was eigentlich passiert. Du könntest jetzt zum Debuggen z. B. ein eigenes Logfile schreiben lassen, in dem Du IP, Zeitstempel, Session-ID, Funktionsnamen und ggf. Script-Namen, aus dem die Logfunktion aufgerufen wurde, speichern lässt.

Dann kannst Du Dir nachher dieses File ansehen und siehst, dass sich z.B. beim Aufruf vom "Logout" die Session-ID gar nicht geändert hat...

Man kann das Gleiche meistens auch schon mit eineigen Kontrollausgaben im Response erreichen, hat nur den Nachteil, dass man sich damit meistens auch das ganze HTML zerschießt und diese Ausgaben dann suchen muss, wo sie denn in der Seite stehen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[AirMax]

Hallo Tom,

erstmal danke für Deine Antwort.

Bei der Fehlersuche in diesem Wechselspiel (Request - Response -Request - Response - usw.) ist es immer ganz hilfreich, sich genaue Übersicht zu verschaffen, was eigentlich passiert. Du könntest jetzt zum Debuggen z. B. ein eigenes Logfile schreiben lassen, in dem Du IP, Zeitstempel, Session-ID, Funktionsnamen und ggf. Script-Namen, aus dem die Logfunktion aufgerufen wurde, speichern lässt.

Ich habe es anders gemacht:
Ich habe den session_save_path(); bei mir lokal mal geändert, um zu sehen, was für Sessions überhaupt gespeichert werden. Dabei habe ich entdeckt, dass, für den Fall, daß Cookies deaktiviert sind, zu viele Sessions erstellt werden (Ich habe vergessen beim logout die SID zu übergeben).
Jetzt funktioniert es aber und es wird genau EINE Session gespeichert (und wieder gelöscht).

Gruß
AirMax

[Tom]

Hello AirMax,

Ich habe den session_save_path(); bei mir lokal mal geändert

Den Session-Save-Path solltest Du sowieso unbedingt in ein Verzeichnis verlegen, auf dass kein anderer User Zugriff hat und wo er auch nicht per HTTP edrreichbar ist.

Wenn PHP als Modul benutzt wird, muss dazu unbedingt auch der open_basedir-Paramter angepasst sein, was aber Aufgabe des Providers wäre...

Anderenfalls sind die Session vermutlich entführbar durch jeden, der auf diesem Server PHP-Scripte betreiben darf, also die anderen Sharing User.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[AirMax]

Hi Tom

Den Session-Save-Path solltest Du sowieso unbedingt in ein Verzeichnis verlegen, auf dass kein anderer User Zugriff hat und wo er auch nicht per HTTP erreichbar ist.

Anderenfalls sind die Session vermutlich entführbar durch jeden, der auf diesem Server PHP-Scripte betreiben darf, also die anderen Sharing User.

Habe keinen Zugriff auf die php.ini :-(