Ankündigung

Einklappen
Keine Ankündigung bisher.

Logout durch Verlust der Session-ID (Zwei IDs pro User?)

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Logout durch Verlust der Session-ID (Zwei IDs pro User?)

    Meine Website hat einen geschützten Mitgliederbereich. Die Login-Kontrolle erfolgt über Sessions. Durch unvollständig aktualisierte Mitgliederprofile habe ich bemerkt, dass bei einigen Usern anscheinend der Login-Status von einer auf die andere Seite verloren geht. Der User ist also plötzlich ausgeloggt. Um der Sache auf die Spur zu kommen, habe ich ein Fehler-Script eingebaut. Aber das machte es für mich nur noch verwirrender. Das Ergebnis stelle ich hier mal dar.

    Etwas viel Text, aber ich denke, man kann da durchsteigen.... Würde mich sehr über Hilfe freuen!



    Login-Seite: Nach erfolgreichem Login wird folgende Session erzeugt:

    PHP-Code:
               session_start();

               
    $_SESSION["login"] = 1;

               
    $_SESSION["fname"] = $fname;
               
    $_SESSION["lname"] = $lname;
               
    $_SESSION["email"] = $email;
               
    $_SESSION["mid"]   = $mid
    mid ist die Mitglieds-ID, es werden außerdem noch Vor- und Zuname sowie E-Mail-Adresse gespeichert.



    Auf jeder Seite im Mitgliederbereich wird jetzt zur Authentifizierung das Script session_control.php aufgerufen.
    Auf diese Seiten kann man eigentlich nur gelangen, wenn man korrekt eingeloggt ist, die Session-ID gesetzt wurde und Cookies nicht deaktiviert sind.
    Trotzdem kommen selten, aber regelmäßig Fehler vor. Ich lasse deshalb error_log.php aufrufen, um mir Seitenname, SID und Inhalt der Session per Mail zusenden zu lassen:

    PHP-Code:

    <?php

      
    // zu schützende Seite


      
    error_reporting(E_ALL);


      include(
    "../inc/connect.php");

      include(
    "../inc/session_control.php");



      if     ( 
    $login <> ) {

               include(
    "../inc/error_log.php"); exit(); }


      ...

    ?>
    PHP-Code:

    <?php

      
    // Seite session_control.php

      
    session_start();


      if    ( isset(
    $_SESSION['login']) ) {


              
    $mid $_SESSION['mid'];

              
    $fname $_SESSION['fname'];
              
    $lname $_SESSION['lname'];
              
    $email $_SESSION['email'];

              
    $login $_SESSION['login']; }

      else {

              
    $mid 0;

              
    $fname "error";
              
    $lname "error";
              
    $email "error";

              
    $login 0; }


      
    $ssid session_id();

    ?>
    PHP-Code:

    <?php

      
    // Seite error_log.php


      
    $url =  $_SERVER['PHP_SELF'] . '?' $_SERVER['QUERY_STRING'];

      
    $print =  print_r($_SESSIONtrue);



      @
    mail ("xxx @ xxx.de","ranking LOGIN ERROR","

      Seite: 
    $url

      SID: 
    $ssid

      
    $print

      Login: 
    $login
      MID: 
    $mid
      Name: 
    $fname $lname

      "
    ,"From: mail@ xxx.de");



      echo 
    "Error: Login invalid";

    ?>


    Zu einer Fehlermeldung habe ich mir die entsprechenden Seitenaufufe aus den Logfiles herauskopiert (darunter zweimal die Fehler-Mail, die durch die vorherige Seite erzeugt wurde) um der Sache auf die Schliche zu kommen. Aber nun wird es nur immer verwirrender:


    Code:
     (1) "GET /members/index.php HTTP/1.1"
     (2) "POST /members/index.php HTTP/1.1"
    
     (3) "GET /ranking/manager.php HTTP/1.1"
     (4) "GET /ranking/ticks_add1.php HTTP/1.1"
     (5) "POST /ranking/ticks_data1.php HTTP/1.1"
     (6) "GET /ranking/ticks_result1.php?PHPSESSID=934c41d34409233d7354a1043107a81d&new=1&dir=1 HTTP/1.1"
     (7) "GET /ranking/sites_add1.php?sort=0 HTTP/1.1" =>FEHLER 1
    
      ------------
      FEHLER 1:
    
      Seite: /ranking/sites_add1.php?sort=0
    
      SID: d328f464fb8e90dd25e6238a4727af78
    
      Array
      (
      )
    
      Login: 0
      MID: 0
      Name: error
    
      --------------
    
     (8) "GET /members/index.php HTTP/1.1" 
    
     (9) "GET /ranking/manager.php HTTP/1.1"
     (10) "GET /ranking/sites_add1.php HTTP/1.1" 
     (11) "POST /ranking/sites_data1.php HTTP/1.1" 
     (12) "GET /ranking/sites_result1.php?PHPSESSID=934c41d34409233d7354a1043107a81d&sort=1&start=100 HTTP/1.1" =>FEHLER 2
    
     ------------
      FEHLER 2:
    
      Seite: /ranking/sites_result1.php?PHPSESSID=934c41d34409233d7354a1043107a81d&sort=1&start=100
    
      SID: d328f464fb8e90dd25e6238a4727af78
    
      Array
      (
      )
    
      Login: 0
      MID: 0
      Name: error
      ------------
    Zur Erläuterung:
    Der User besucht die Startseite des Mitgliederbereichs (1), muss sich aber erst noch einloggen: via POST (2)
    Login anscheinend erfolgreich, denn der User gelangt auf die geschützte Seite 'manager.php' (3)

    Der User möchte nun sein Mitgliederprofil bearbeiten (4)(5)(6). Dies erfolgt mit den drei Seiten mit den Endungen _add1.php (Formular), _data1.php (Verarbeitung der Formulardaten, dann Header-Weiterleitung zur nächsten Seite), _result1.php (Anzeige der Änderungen für den User)

    Weil mit der Header-Weiterleitung öfter Cookies verloren gingen (Warum konnte mir auch noch keiner erklären), habe ich hier die zusätzliche Übergabe der SID via GET erzwungen.

    Der User geht jetzt über einen Link zu einer weiteren Seite um bestimmte Mitglieder-Daten zu aktualisieren (7). Hier tritt der erste Fehler auf:
    In der Fehler-Mail sieht man, dass die ursprüngliche Session-ID (die mit "934.." beginnt), offenbar beim Übergang von (6) zu (7) verlorengegangen ist.
    Durch session_start(); wurde eine neue SID erzeugt ("d32.."), die natürlich noch leer ist. Somit ist login=0, dem User wird eine Fehlermeldung angezeigt, das Script bricht ab.

    Der User geht nun zurück zur index-Seite (8 ), loggt sich erneut ein und versucht es noch einmal (10)(11)(12). Er kommt diesmal auch etwas weiter, erst bei der result-Seite tritt der Fehler wieder auf.

    Nun aber das Mysteriöse: Bei (12) taucht in der URL plötzlich wieder die ursprüngliche SID ("934...") auf, die ja eigentlich schon gelöscht und durch ("d32..") überschrieben wurde. Wie kann das sein? Können für einen User zwei SID angelegt werden?? (einer über GET, einer über Cookies??). Oder habe ich hier was grundlegendes übersehen? Diese Fehler kommen wie gesagt nur bei einigen Usern vor, aber trotzdem nicht gerade selten.


  • #2
    Naja, weisst Du denn, wie die User navigieren? Die zusätzliche SID über GET wäre für mich der heißeste Kandidat. Ich weiß jetzt nicht, welche ID in diesem Fall auswertet, aber vielleicht werden hier zwei IDs geführt und wenn das Cookie nicht übertragen wird, ist die alte Session wieder aktiviert.
    --

    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


    --

    Kommentar


    • #3
      Zitat von nikosch Beitrag anzeigen
      Naja, weisst Du denn, wie die User navigieren?
      Ja, ich konnte das ja über die Logfiles exakt nachvollziehen. Außerdem kam derselbe Fehler bei mehreren Usern vor.


      Zitat von nikosch Beitrag anzeigen
      Die zusätzliche SID über GET wäre für mich der heißeste Kandidat. Ich weiß jetzt nicht, welche ID in diesem Fall auswertet, aber vielleicht werden hier zwei IDs geführt und wenn das Cookie nicht übertragen wird, ist die alte Session wieder aktiviert.
      Das Komische ist ja: die erzwungene SID über GET gibt es nur bei einer einzigen Seite _result.php, die durch header-Weiterleitung aufgerufen wird.
      Diese SID wurde offensichtlich ignoriert und eine neue Session gestartet. Aber beim zweiten Versuch ist die alte SID in der URL dann plötzlich wieder da, obwohl diese wie gesagt nicht über GET von Seite zu Seite übergeben wurde, sondern auf der vorigen Seite per session_id(); erzeugt wurde.
      Irgendwie fehlt mir hier jeder Erklärungsansatz....

      Kommentar


      • #4
        Ich denke, ich habe jetzt die Erklärung (aber leider keine Lösung..)

        Nochmal kurz zum Problem: Ich hatte bemerkt, dass bei einigen Usern immer ein automatischer Logout nach einer Header-Weiterleitung stattfindet. Die Login-Daten wurden hierbei als Cookie übergeben, wurden aber anscheinend nicht ausgelesen. Ich bin dann auf Sessions umgestiegen, inkl. Weitergabe der SID in der URL. Aber auch hier wurde die SID nicht berücksichtigt, stattdessen wurde eine neue erstellt. Kurioserweise tauchte die alte SID später z.T. wieder auf (s.o.).

        Erklärung: Es kann eigentlich nur so sein, dass der Server nach der Header-Weiterleitung den Browser/Computer des Users aus irgendeinem Grund nicht mehr korrekt identifizieren kann. Für den Server war der User somit neu; Cookies wurden nicht mehr zugeordnet, es wurde eine neue SID vergeben. Wenn der Browser sich dann später wieder richtig "ausweist", wird auch wieder die alte SID verwendet.

        Frage: Ist das Problem mit der Weiterleitung irgendjemandem bekannt. Lässt sich das evtl. lösen, indem man bei der Weiterl. irgendwelche Header-Daten mit übergibt.

        Mein Server hat das Suhosin Sicherheits-Patch phpinfo(). Ich vermute stark, dass es damit etwas zu tun hat. Hat jemand eine Idee, welchen Wert man dort ändern könnte, um das Problem zu lösen (Ich kann die php.ini nicht selbst ändern, der Greatnet-Support hilft da aber weiter, nur wäre es da natürlich gut zu wissen, was ich denen sagen soll...)
        Vielen Dank!

        Kommentar


        • #5
          hm.. nach dem login , benutzer daten in session speichern ist logisch.. aber danach? session_control.php? wozu soll es gut sein die session in variable zu speichern und dann mit dieser variable weiter arbeiten? wieso nicht gleich?

          PHP-Code:

            
          if     ( $_SESSION['login']<> ) {

                     include(
          "../inc/error_log.php"); exit(); } 
          besser wäre nach dem login

          PHP-Code:
          $_SESSION['login'] = session_id(); 
          und danach
          PHP-Code:

            
          if     ( $_SESSION['login']<> session_id() ) {

                     include(
          "../inc/error_log.php"); exit(); } 
          und ich sehe in deiner zu schützenden seite kein session_start() am anfang... das wären halt so dinge die mir aufgefallen sind... eventuell hilfts dir weiter
          apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp | Mein Youtube PHP Kanal: https://www.youtube.com/c/VitalijMik

          Kommentar


          • #6
            Zitat von BlackScorp Beitrag anzeigen
            hm.. nach dem login , benutzer daten in session speichern ist logisch.. aber danach? session_control.php? wozu soll es gut sein die session in variable zu speichern und dann mit dieser variable weiter arbeiten?
            Danke für den Tipp! Allerdings scheint es ja bei mir nicht falsch zu sein, sondern höchstens etwas umständlicher. Wie gesagt, das Problem tritt nur bei einigen Usern auf (max. 5%), bei den anderen läuft alles korrekt.

            Der Fehler muss irgendwo in der Kommunikation Server/Browser liegen. Und da tippe ich stark auf Suhosin.

            Zitat von BlackScorp Beitrag anzeigen
            und ich sehe in deiner zu schützenden seite kein session_start() am anfang...
            in der includierten Datei session_control.php

            Kommentar


            • #7
              dann muss der fehler an einer anderen stelle liegen... vielleicht kommt der fehler wenn man NUR eine bestimmte seite aufruft?? oder ist es seiten unabhängig?
              apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp | Mein Youtube PHP Kanal: https://www.youtube.com/c/VitalijMik

              Kommentar


              • #8
                Solche Probleme, die „nur manchmal auftreten“, sind immer schwer zu analysieren. Allerdings kann man an sowas m.E. auch nicht rangehen, in dem man nur sagt, „bei manchen Usern tritt das auf“ - da muss man die Umstände schon etwas genauer betrachten: Welche(n) Browser nutzen die, gibt's irgendwelche Firewalls etc., die mit reinspielen könnten, etc.

                Zitat von oriolus Beitrag anzeigen
                Die Login-Daten wurden hierbei als Cookie übergeben, wurden aber anscheinend nicht ausgelesen. Ich bin dann auf Sessions umgestiegen, inkl. Weitergabe der SID in der URL.
                Wie jetzt, ich dachte du hättest von Anfang an Sessions benutzt?

                Aber auch hier wurde die SID nicht berücksichtigt, stattdessen wurde eine neue erstellt. Kurioserweise tauchte die alte SID später z.T. wieder auf (s.o.).
                Na ja, wenn der Client dann wieder seinen alten Cookie-Inhalt, also die alte Session-ID, mitschickt, ist das nicht verwunderlich.

                Erklärung: Es kann eigentlich nur so sein, dass der Server nach der Header-Weiterleitung den Browser/Computer des Users aus irgendeinem Grund nicht mehr korrekt identifizieren kann. Für den Server war der User somit neu; Cookies wurden nicht mehr zugeordnet, es wurde eine neue SID vergeben.
                Na ja, das war ja wohl schon von vornherein klar ...

                Btw., Cookies ordnet nicht der Server irgendeinem Client zu. Cookies sendet der Client, wenn er sie akzeptiert hat, beim nächsten Request einfach wieder mit, sofern die Bedingungen stimmen (Domain, ggf. Path).

                Frage: Ist das Problem mit der Weiterleitung irgendjemandem bekannt.
                Ich kann mich schon an einige ähnliche Fragestellungen aus anderen Foren erinnern, wo es auch Probleme mit Sessions in Kombination mit Weiterleitungen gab.
                Exlizite Weitergabe der SID im URL hat dann aber meist, soweit ich mich erinnern kann, das Problem lösen können.

                Lässt sich das evtl. lösen, indem man bei der Weiterl. irgendwelche Header-Daten mit übergibt.
                Was meinst du mit „Header-Daten“?

                Wenn du schon die Session-ID explizit per GET mit übergibst, und das zu dem Zeitpunkt auch die richtige ist - dann sollte das eigentlich ausreichen, um auf der Zielseite der Weiterleitung dann auch ganz sicher Zugriff auf die SID zu haben.

                Problematisch könnte es dann höchstens sein, wenn der Client zusätzlich zur SID im Querystring auch noch eine per Cookie mitschickt, und die voneinander abweichen. Dann kommt ggf. noch die Reihenfolge zum tragen, in der GET- und COOKIE-Parameter ausgewertet werden.
                Aber auch dann müsste vorher schon ein Fehler in deiner Applikation passiert sein, sonst dürfte es auch an dieser Stelle keine zwei SIDs geben.

                Mein Server hat das Suhosin Sicherheits-Patch phpinfo(). Ich vermute stark, dass es damit etwas zu tun hat.
                Das wäre zwar auch denkbar, aber die Werte/Einschränkungen bzgl. Cookies und Sessions, die Suhosin machen kann, sehen mir in der gezeigten phpinfo-Ausgabe auch erst mal unverdächtig aus.
                Gibt es vielleicht die Möglichkeit, suhosin ein Logfile schreiben zu lassen, wenn es aus irgendeinem Grund bspw. einen per Cookie übermittelten Wert ablehnt/ausfiltert?

                Kommentar


                • #9
                  Zitat von ChrisB Beitrag anzeigen
                  Solche Probleme, die „nur manchmal auftreten“, sind immer schwer zu analysieren. Allerdings kann man an sowas m.E. auch nicht rangehen, in dem man nur sagt, „bei manchen Usern tritt das auf“ - da muss man die Umstände schon etwas genauer betrachten: Welche(n) Browser nutzen die, gibt's irgendwelche Firewalls etc., die mit reinspielen könnten, etc.
                  Naja, ich kenne ja nicht alle User persönlich. Von Zweien weiß ich, dass sie Firefox benutzten. Mit einem anderen Browser trat das Problem nicht mehr auf.

                  Zitat von ChrisB Beitrag anzeigen
                  Wie jetzt, ich dachte du hättest von Anfang an Sessions benutzt?
                  Ganz am Anfang lief der Login nur über Cookies. Erst später bin ich auf Sessions umgestiegen, um die SID per GET zu übergeben - das war jetzt nur ein Ausflug in die Historie, wie ich den Fehler entdeckt habe.

                  Zitat von ChrisB Beitrag anzeigen
                  Na ja, wenn der Client dann wieder seinen alten Cookie-Inhalt, also die alte Session-ID, mitschickt, ist das nicht verwunderlich.
                  Genau. Aber wie gesagt: Selbst wenn die SID erzwungen über die URL mitgegeben wird, wird diese ignoriert und eine neue angelegt. Das kann ich mir nur damit erklären, dass der Browser/User nicht erkannt wird.

                  Zitat von ChrisB Beitrag anzeigen
                  Ich kann mich schon an einige ähnliche Fragestellungen aus anderen Foren erinnern, wo es auch Probleme mit Sessions in Kombination mit Weiterleitungen gab.
                  Ja, ich hab da auch einiges gelesen. Dort war es aber fast immer so, dass die SID im selben Script erzeugt wurde, in dem sich weiter unten die Weiterleitung befindet. Das funktioniert dann nicht, ist bei mir aber nicht der Fall.

                  Zitat von ChrisB Beitrag anzeigen
                  Exlizite Weitergabe der SID im URL hat dann aber meist, soweit ich mich erinnern kann, das Problem lösen können.
                  Tja, bei mir leider nicht...

                  Zitat von ChrisB Beitrag anzeigen
                  Was meinst du mit „Header-Daten“?
                  ich hatte in verschiedenen Scripts gesehen, dass vor der Weiterleitung noch andere Header gesendet wurden, die ich z.T. nicht verstanden habe (z.B. sowas: header('Status: 303 See Other'); ). Da dachte ich, dass evtl. noch Header-Daten fehlen könnten, womit sich der Browser authentifiziert.

                  Zitat von ChrisB Beitrag anzeigen
                  Wenn du schon die Session-ID explizit per GET mit übergibst, und das zu dem Zeitpunkt auch die richtige ist - dann sollte das eigentlich ausreichen, um auf der Zielseite der Weiterleitung dann auch ganz sicher Zugriff auf die SID zu haben.
                  Eigentlich ja. Ich habe ja im Grunde eine ganz simple User-Authentifizierung per SID, die eigentlich auch funktioniert.
                  Nur wenn irgendwo mal eine Header-Weiterleitung dazwischen ist, tritt bei einigen Usern dieser Fehler auf.
                  Dass die SID vom Client nicht mitgesendet wurde, kann ich durch die Übergabe per URL ausschließen.
                  Somit bleibt m.E. nur die Erklärung, dass der Server sich aus irgendeinem Grund "weigert", die SID zu verarbeiten. Und da kommt evtl. Suhosin ins Spiel....

                  Zitat von ChrisB Beitrag anzeigen
                  Gibt es vielleicht die Möglichkeit, suhosin ein Logfile schreiben zu lassen, wenn es aus irgendeinem Grund bspw. einen per Cookie übermittelten Wert ablehnt/ausfiltert?
                  ich habe leider keinen Zugang zu den Error Logs (oder kann man irgendwie per Php-Script darauf zugreifen?)

                  Danke für die ausführliche Antwort!

                  Kommentar


                  • #10
                    Zitat von oriolus Beitrag anzeigen
                    Ganz am Anfang lief der Login nur über Cookies. Erst später bin ich auf Sessions umgestiegen, um die SID per GET zu übergeben
                    Da sehe ich immer noch keinen wirklichen Zusammenhang.
                    Sessions sind Sessions, egal auf welchem Wege du die Session-ID übergibst, ob per Cookie oder als GET-Parameter.
                    Und deine ursprüngliche Erklärung klang eher so, als ob du von Anfang an Sessions benutzt hättest, nur eben mit Übergabe der SID ausschliesslich per Cookie.

                    Genau. Aber wie gesagt: Selbst wenn die SID erzwungen über die URL mitgegeben wird, wird diese ignoriert und eine neue angelegt. Das kann ich mir nur damit erklären, dass der Browser/User nicht erkannt wird.
                    Wenn der Client wiedererkannt wird, dann an hand der Session-ID, die er beim Request mitschickt.
                    Wird er nicht erkannt, dann hat er keine mitgeschickt. Oder der Server hat sie von selber ausgefiltert/verworfen (suhosin). Welches von beiden die Ursache ist, ist zu untersuchen.



                    Eigentlich ja. Ich habe ja im Grunde eine ganz simple User-Authentifizierung per SID, die eigentlich auch funktioniert.
                    Nur wenn irgendwo mal eine Header-Weiterleitung dazwischen ist, tritt bei einigen Usern dieser Fehler auf.
                    Dass die SID vom Client nicht mitgesendet wurde, kann ich durch die Übergabe per URL ausschließen.
                    Kannst du? Du hast die SID zuerst zum Client geschickt, mit deiner Weiterleitung.
                    Ob der Client sie auch wieder zurück geschickt hat, ist zu überprüfen - hast du entsprechende, eindeutige Anhaltspunkte, dass das der Fall war? (Auftauchen der SID in der Adresszeile des Browsers wäre bei Übergabe per GET recht eindeutig.)

                    Somit bleibt m.E. nur die Erklärung, dass der Server sich aus irgendeinem Grund "weigert", die SID zu verarbeiten. Und da kommt evtl. Suhosin ins Spiel....
                    Ein entsprechendes Test-Beispiel, ggf. mit zwei, drei Scripten, die eine Session starten, untereinander weiterleiten, und dann den aktuellen Session-Inhalt jeweils irgendwo protokollieren (Direktausgabe geht bei Weiterleitung ja schlecht), sollte schnell geschrieben sein.

                    Wenn das bei deinem Test dann problemlos läuft, keine Fehler auftreten, auch im Test mit verschiedenen Browsern und unterschiedlichen Client-Einstellungen, was bspw. Cookie-Annahme angeht - dann musst du wirklich noch mal an die Nutzer ran, die Probleme damit haben. Dann müssen die genauer die Umstände beschreiben, ggf. auch mal dein Test-Script selber von ihrem Rechner aus aufrufen - damit du auswertbare, aussagekräftige Informationen bekommst.

                    ich habe leider keinen Zugang zu den Error Logs (oder kann man irgendwie per Php-Script darauf zugreifen?)
                    Dann frag' deinen Hoster, ob suhosin entsprechende Filterungen protokolliert bzw. sich das ggf. aktivieren lässt.
                    Zusammen mit dem Zugriffszeitpunkt des nächsten Nutzers, der Probleme meldet, ließe sich daran dann vielleicht was erkennen.

                    Kommentar


                    • #11
                      Zitat von ChrisB Beitrag anzeigen
                      Kannst du? Du hast die SID zuerst zum Client geschickt, mit deiner Weiterleitung.
                      Ob der Client sie auch wieder zurück geschickt hat, ist zu überprüfen - hast du entsprechende, eindeutige Anhaltspunkte, dass das der Fall war? (Auftauchen der SID in der Adresszeile des Browsers wäre bei Übergabe per GET recht eindeutig.)
                      Hier nochmal ein Ausschnitt aus dem Fehler-Abfang-Script:

                      PHP-Code:
                      <?php 

                        session_start
                      ();

                        
                      $url =  $_SERVER['PHP_SELF'] . '?' $_SERVER['QUERY_STRING']; 

                        
                      $print =  print_r($_SESSIONtrue); 

                        
                      $ssid session_id();


                        @
                      mail ("an_mich @ club300.de","LOGIN ERROR",

                        Seite: 
                      $url 

                        SID: 
                      $ssid 

                        
                      $print 

                        "
                      ,"From: mail @ club300.de"); 

                      ?>
                      und hier eine beispielhafte daraus resultierende Mail an mich:

                      Code:
                        Seite: /profil/add_result.php?PHPSESSID=166b3a93ad504d344ce3bbee109f2e65&new=1&dir=1
                      
                        SID: a03664b53bc542ffdd91a3ce4e862c11
                      
                        Array
                      (
                      )
                      Wie du siehst, wurde die SID per URL übergeben, aber ignoriert. Stattdessen wurde eine neue SID generiert (noch leer)


                      Zitat von ChrisB Beitrag anzeigen
                      Ein entsprechendes Test-Beispiel, ggf. mit zwei, drei Scripten, die eine Session starten, untereinander weiterleiten, und dann den aktuellen Session-Inhalt jeweils irgendwo protokollieren (Direktausgabe geht bei Weiterleitung ja schlecht), sollte schnell geschrieben sein.

                      Wenn das bei deinem Test dann problemlos läuft, keine Fehler auftreten, auch im Test mit verschiedenen Browsern und unterschiedlichen Client-Einstellungen, was bspw. Cookie-Annahme angeht - dann musst du wirklich noch mal an die Nutzer ran, die Probleme damit haben. Dann müssen die genauer die Umstände beschreiben, ggf. auch mal dein Test-Script selber von ihrem Rechner aus aufrufen - damit du auswertbare, aussagekräftige Informationen bekommst.
                      Diesen Test gibt es: http://www.club300.de/test2/seite1.php

                      Code spar ich mir jetzt mal: auf der ersten Seite wird $login = "okay"; in eine Session geschrieben. Auf der 2. Seite wieder ausgegeben. Auf der 3. ebenso, nur dass hier noch eine Weiterleitung zwischengeschaltet ist. Drei "Problem-User" haben das getestet: 2x alles okay, 1x wie erwartet Abbruch bei Seite 3 (der Fehler tritt also auch hier nicht immer auf)

                      Kommentar

                      Lädt...
                      X