Hank: Session Problem php

Die Funktion session_status() gibt den aktuellen Status der PHP-Session zurück. Es kann eine der folgenden vier integer-Werte zurückgeben:

PHP_SESSION_DISABLED (0): Die PHP-Session ist deaktiviert oder kann nicht verwendet werden.

PHP_SESSION_NONE (1): Die PHP-Session ist aktiviert, aber es wurde noch keine Sitzung gestartet.

PHP_SESSION_ACTIVE (2): Eine PHP-Session ist aktiv und eine Sitzung wurde gestartet.

PHP_SESSION_DISABLED_BY_RUNTIME (3): Die PHP-Session wurde zur Laufzeit deaktiviert, beispielsweise durch die Verwendung der Funktion session_start().

warum erhalte ich als Ausgabe bei folgendem php-code in der letzten zeile eine 1, obwohl die Session ja gestartet sein sollte?

echo "Session-Status_vor_start = ".session_status();
// Prüfen, ob eine Sitzung bereits gestartet wurde
if(session_status() != 2) {
    // Sitzung starten
    session_start();
}
echo "Session-Status_nach_start = ".session_status();

Eine Änderung auf if(session_status() == PHP_SESSION_NONE) { bringt dasselbe Ergebnis.

Hank

  1. Versuch 1:

    <?php
    echo "Session-Status_vor_start = ".session_status() . PHP_EOL;
    // Prüfen, ob eine Sitzung bereits gestartet wurde
    if( session_status() != 2 ) {
        // Sitzung starten
        session_start();
    }
    echo "Session-Status_nach_start = " . session_status() . PHP_EOL;
    
    

    Run (Im Terminal, Output-Buffering ist also deaktiviert):

    • Session-Status_vor_start = 1
    • PHP Warning: session_start(): Session cannot be started after headers have already been sent in test.php on line 6
    • Session-Status_nach_start = 1

    Versuch 2, ob_start() wird verwendet:

    <?php
    ob_start();
    echo "Session-Status_vor_start = ".session_status() . PHP_EOL;
    // Prüfen, ob eine Sitzung bereits gestartet wurde
    if( session_status() != 2 ) {
        // Sitzung starten
        session_start();
    }
    echo "Session-Status_nach_start = " . session_status() . PHP_EOL;
    
    

    Run: (Wie vor)

    • Session-Status_vor_start = 1
    • Session-Status_nach_start = 2

    Frage: Wie hast Du getestet?

    1. Hallo Raketenwilli,

      Frage: Wie hast Du getestet?

      ob_start();

      hat bei mir nichts an der Ausgabe geändert.

      Hank

  2. Hallo Hank,

    warum erhalte ich als Ausgabe bei folgendem php-code in der letzten zeile eine 1, obwohl die Session ja gestartet sein sollte?

    echo "Session-Status_vor_start = ".session_status();
    // Prüfen, ob eine Sitzung bereits gestartet wurde
    if(session_status() != 2) {
        // Sitzung starten
        session_start();
    }
    echo "Session-Status_nach_start = ".session_status();
    

    weil du mit dem echo in der ersten Zeile die erste Ausgabe machst. Damit werden die HTTP-Header für die Seite gesendet und können danach nicht mehr geändert oder ergänzt werden. Das session_start() möchte eigentlich ein Cookie setzen, kann das aber nicht mehr und bleibt deshalb wirkungslos.

    Saubere Lösung: Gib den Wert in der ersten Zeile nicht direkt aus, sondern speichere ihn nur und mach alle Ausgaben später im Script en bloc.

    The dirty way: Nutze Output Buffering.

    Einen schönen Tag noch
     Martin

    --
    Kaffee ist nur schädlich, wenn Ihnen ein ganzer Sack aus dem 5. Stock auf den Kopf fällt.
    1. Hallo Martin, hallo Raketenwilli,

      danke für Eure Antworten.

      weil du mit dem echo in der ersten Zeile die erste Ausgabe machst. Damit werden die HTTP-Header für die Seite gesendet und können danach nicht mehr geändert oder ergänzt werden. Das session_start() möchte eigentlich ein Cookie setzen, kann das aber nicht mehr und bleibt deshalb wirkungslos.

      Saubere Lösung: Gib den Wert in der ersten Zeile nicht direkt aus, sondern speichere ihn nur und mach alle Ausgaben später im Script en bloc.

      Bezieht sich das auf die Webseite insgesamt oder auf den <body> der webseite?

      Ich frage, weil ich das dann ja in die head.php eintragen muss und dort vor dem eigentlichen php-Teil ein html-Teil kommt, der den <html> und den <head> Teil der Webseite entzhält.

      Hank

      1. Ich frage, weil ich das dann ja in die head.php eintragen muss und dort vor dem eigentlichen php-Teil ein html-Teil kommt, der den <html> und den <head> Teil der Webseite entzhält.

        Wird der "html-Teil" ausgegeben?

        • Ja!

        Verhindern diese Ausgaben das Senden weiterer Header?

        • Ja!

        Was musst Du also tun?

        1. Hi,

          Wird der "html-Teil" ausgegeben?

          • Ja!

          Verhindern diese Ausgaben das Senden weiterer Header?

          • Ja!

          Was musst Du also tun?

          Habe es schon gemacht.
          Neuer php-Teil noch vor den ersten html-Teil und jetzt erhalte ich auch Status = 2.

          Warum ich das alles gemacht habe, damit ich ein CSRF token in ein Formular einsetzen kann.

          Ich habe noch nicht zu 100% verstanden, warum das genau wichtig ist. Können Spambots den token nicht auch aus dem Formular auslesen und ihn mitsenden?

          Hank

          1. Können Spambots den token nicht auch aus dem Formular auslesen und ihn mitsenden?

            Klar. Aber das setzt voraus, dass die Spammer den Aufwand treiben. Das sind aber Leute, denen (manchmal von sich selbst) versprochen wurde, „einfach und von zu Hause aus viel Geld zu verdienen“. Individuelle Anpassungen sind da aus (nennen wir sie euphemistisch) „ökonomischen“ Gründen einfach nicht drin.

            1. Können Spambots den token nicht auch aus dem Formular auslesen und ihn mitsenden?

              Klar. Aber das setzt voraus, dass die Spammer den Aufwand treiben. Das sind aber Leute, denen (manchmal von sich selbst) versprochen wurde, „einfach und von zu Hause aus viel Geld zu verdienen“. Individuelle Anpassungen sind da aus (nennen wir sie euphemistisch) „ökonomischen“ Gründen einfach nicht drin.

              Ich habe gerade Ärger mit einem Bot. Der ist zu doof, ein Subject-Input-Feld mit einem Betreff zu füllen, nur weil das input-field als name den wert phone hat, aber er scheint den token auszulesen. Finde ich merkwürdig.

                elseif ($_SESSION['token'] != $_POST['token']) {
              ...
              } elseif (...) {
              ...
              // der Bot kommt bis hierher
              
              

              Finde ich komisch.

              Hank

              1. Ich habe gerade Ärger mit einem Bot. Der ist zu doof, ein Subject-Input-Feld mit einem Betreff zu füllen, nur weil das input-field als name den wert phone hat, aber er scheint den token auszulesen. Finde ich merkwürdig.

                  elseif ($_SESSION['token'] != $_POST['token']) {
                ...
                } elseif (...) {
                ...
                // der Bot kommt bis hierher
                
                

                Nun, so lange ich nicht die gesamte Entscheidungsstruktur und die Bedingungen sehen kann, kann ich zwar nicht wirklich beurteilen, ob das „komisch“ ist, da aber ein Programm bei identischen Daten und Einstellungen immer gleich reagiert vermute ich, dass das weniger „komisch“ als viel mehr „zwingend“ ist.

                Wenn also steht

                <?php
                $foo = false;
                $bar = true;
                $tok = true;
                
                if ( $foo ) {
                   echo 'foo ist true'. PHP_EOL;
                } elseif ( ! $bar ) {
                   echo 'bar ist false'. PHP_EOL;
                } elseif ( $tok ) {
                   echo 'tok ist true'. PHP_EOL;
                }
                

                Dann wundere ich mich keine Sekunde Minute darüber, dass

                tok ist true
                

                ausgegeben wird.

                Fazit:

                Untersuche die Logik. Irgendetwas ist anders als von Dir erwartet. Auf jeden Fall ist es wie von Dir notiert.

                1. Nun, so lange ich nicht die gesamte Entscheidungsstruktur und die Bedingungen sehen kann, kann ich zwar nicht wirklich beurteilen, ob das „komisch“ ist, da aber ein Programm bei identischen Daten und Einstellungen immer gleich reagiert vermute ich, dass das weniger „komisch“ als viel mehr „zwingend“ ist.

                  
                  // Prüfen, ob ein token bekannt ist
                  if(!isset($_SESSION['token'])) {
                      $token = bin2hex(random_bytes(32)); // 32-byte CSRF-Token generieren
                      $_SESSION['token'] = $token;
                  }
                  
                  if($_POST['formsend']) {
                      $name = $_POST['author'] ?? null;
                      $email = $_POST['email'] ?? null;
                      $subject = $_POST['phone'] ?? null;
                      $emailmessage = $_POST['text'] ?? null;
                  
                      if(is_null($name) || $name == '') {
                          $_POST['formsend'] = false;
                          //Fehlermeldung
                      } elseif(is_null($email) || filter_var($email,FILTER_VALIDATE_EMAIL) == false) {
                          $_POST['formsend'] = false;
                          //Fehlermeldung
                      } elseif($_SESSION['token'] != $_POST['token']) {
                          // Action if the token is not valid
                          $_POST['formsend'] = false;
                          $bot = 1;
                          $meldung = 'Spambot - Token passt nicht';
                          // Fehlermeldung
                      } elseif($nur_ziffern_ausgefuellt) {
                          $_POST['formsend'] = false;
                          $bot = 1;
                          $meldung = 'Spambot - Kein valides Subject';
                          //Fehlermeldung
                      }
                      
                      if($bot == 1) {
                          // mail an mich senden, dass Bot am werk war
                      }
                  }
                  if($_POST['formsend']) {
                      // mails an mich und Ausfüller senden
                  } else {
                      echo('	
                  			
                              <div id="contact_form">
                                 <form method="post" name="contact" action=/kontakt>
                                      <input type="hidden" name="token" value="'.$_SESSION['token'].'" />
                                     <input type="hidden" name="formsend" value="true" />
                                     <label for="author">Name:</label> 
                                      <input type="text" id="author" name="author" class="required input_field" value="'.$name.'" />
                                      <label for="email">Email:</label> 
                                      <input type="text" id="email" name="email" class="validate-email required input_field" value="'.$email.'" />
                                      
                                      <label for="phone">Betreff:</label> 
                                      <input type="text" name="phone" id="phone" class="input_field" value="'.$subject.'" />
                      
                                      <label for="text">Nachricht:</label> 
                                      <textarea id="text" name="text" rows="0" cols="0" class="required">'.$emailmessage.'</textarea>
                                      
                                      <input type="submit" class="submit_btn" name="submit" id="submit" value="Send" />
                                      
                                  </form>
                              </div>     
                              ');
                  }
                  
                  

                  Und die Emails, die mich erreichen, haben die Meldung:

                  Spambot - Kein valides Subject

                  1. Und die Emails, die mich erreichen, haben die Meldung:

                    Spambot - Kein valides Subject

                    Ok. Untersuchung:

                    Um zu dieser Ausgabe vorzudringen muss der kleine Mann namens PHP (Peter Hat Programm) folgende Daten vorfinden:

                    if($_POST['formsend']) {
                    
                    • $_POST['formsend'] ist truly (nicht: false, null, 0 oder '')
                    if(is_null($name) || $name == '') {
                    
                    • UND NICHT $name ist null oder leer.
                    } elseif(
                           is_null($email) 
                        || filter_var( $email,FILTER_VALIDATE_EMAIL) == false
                    ) {
                    
                    • UND $email ist nicht null
                    • UND filter_var( $email,FILTER_VALIDATE_EMAIL) ist nicht falsy
                    } elseif($_SESSION['token'] != $_POST['token']) {
                    
                    • UND $_SESSION['token'] und $_POST['token'] stimmen grob (nicht typsicher) überein - was aber auch zutrifft, wenn diese jeweils entweder leer, 0 oder false sind…
                    } elseif($nur_ziffern_ausgefuellt) {
                    
                    • UND $nur_ziffern_ausgefuellt ist truely. Was aber z.B. auch zutrifft, wenn es „0“ (Den String „0"!) enthält.

                    Und jetzt geh debuggen: Lass Dir ausgeben, was drin steht. Vergleiche das mit Deinen Erwartungen.


                    Begriffe:

                    • truely: Ein nicht typsicherer Vergleich mit true matcht: if ( $foo )
                    • falsy : Ein nicht typsicherer Vergleich mit false matcht. if ( ! $foo )
                    1. echo ("Formsend: ".$_POST['formsend']."<br>");
                      echo ("Name: ".$name."<br>");
                      echo ("Email: ".$email."<br>");
                      echo ("Session token: ".$_SESSION['token']."<br>");
                      echo ("Post token: ".$_POST['token']."<br>");
                      echo ("Subject: ".$subject."<br>");
                      

                      ergibt:

                      Formsend: true
                      Name: MyName
                      Email: mymail@example.com
                      Session token: 59b5ba4a02ee13338388c8affc76a7586ed228d6fc77a8c95cdad66b2029b56e
                      Post token: 59b5ba4a02ee13338388c8affc76a7586ed228d6fc77a8c95cdad66b2029b56e
                      Subject: MySubject
                      

                      Aber ich habe das Formular ja auch über Browser aufgerufen.

                      1. Genau. Es fehlt nur ein nicht-falsches $nur_ziffern_ausgefuellt ... dann kommt Deine Fehlermeldung „Spambot - Kein valides Subject“.

                      2. Aber ich habe das Formular ja auch über Browser aufgerufen.

                        Aber mein Log zeigt an, dass der Bot den token anscheinend ausliest:

                        Session token: 4b232cba33da1b19d8ab81b1bbdd43068b5d8689a24610121142842c3ceebb96 Post token: 4b232cba33da1b19d8ab81b1bbdd43068b5d8689a24610121142842c3ceebb96

                        Das kann er, aber einen Betreff in ein vermeintliches phone-input-field setzen, dazu ist er zu doof. 😜

                        1. Der Gag ist, das Token nicht selbst ins Formular zu schreiben sondern dieses durch JS erledigen zu lassen. Die Crux an einem „gemeinsamen Geheimnis“ ist, dieses eben nicht mit der gleichen Post wie die Anforderung zu senden.

                          Liebe Elsa!

                          Um zu beweisen, dass Du selbst diesen Brief geschrieben hast, unterschreibe die Antwort mit „Deine liebste Kuh!“

                          Dein, auf immer dummer Ochse

                          Wenigstens könntest Du erwarten, dass mittels JS das Token in einer Weise verändert wird, die für Spammer nicht ganz so einfach zu kopieren ist:

                          Du kannst das hier versuchen:

                          Im Browser:

                          1. Geladen wird die Webseite mit dem Token.
                          2. Via JS wird ein Salt geholt (der auch in die Session geschrieben wird)
                          3. Salt und Token werden verbunden und gehasht, Das Ergebnis als Token ins Formular geschrieben.

                          Auf dem Server beim Empfang:

                          Salt und Token werden aus der Session geholt, gehasht und das Ergebnis mit dem Hash verglichen, den der Browser nunmehr als Token gesendet hat.

                          Allerdings hier gleich der Hinweis, dass auch dieses einen ersthaft agierenden Angreifer nicht abhalten kann. Es macht die Sache für ihn nur komplizierter. Rot13 wäre ähnlich effektiv...

                          Eine Frage: Warum sind die Versender überhaupt so hartnäckig? Kann man mit Deinem dollen Ding etwa Mails an Dritte versenden?

                          Dann gilt die folgende, einfache Regel: Der Benutzer bestimmt entweder den Empfänger ODER (Subjekt oder jeglichen Inhalt) der Nachricht).

                          Captcha:

                          • Hast Du sowas schon versucht?
                          1. Der Gag ist, das Token nicht selbst ins Formular zu schreiben sondern dieses durch JS erledigen zu lassen. Die Crux an einem „gemeinsamen Geheimnis“ ist, dieses eben nicht mit der gleichen Post wie die Anforderung zu senden.

                            Stimmt.
                            Oder aber etwas Intelligenz beim Zusammensetzen des Token zu verwenden.

                            Liebe Elsa!

                            Um zu beweisen, dass Du selbst diesen Brief geschrieben hast, unterschreibe die Antwort mit „Deine liebste Kuh!“

                            Dein, auf immer dummer Ochse

                            Wenigstens könntest Du erwarten, dass mittels JS das Token in einer Weise verändert wird, die für Spammer nicht ganz so einfach zu kopieren ist:

                            Du kannst das hier versuchen:

                            Im Browser:

                            1. Geladen wird die Webseite mit dem Token.
                            2. Via JS wird ein Salt geholt (der auch in die Session geschrieben wird)
                            3. Salt und Token werden verbunden und gehasht, Das Ergebnis als Token ins Formular geschrieben.

                            Auf dem Server beim Empfang:

                            Salt und Token werden aus der Session geholt, gehasht und das Ergebnis mit dem Hash verglichen, den der Browser nunmehr als Token gesendet hat.

                            Allerdings hier gleich der Hinweis, dass auch dieses einen ersthaft agierenden Angreifer nicht abhalten kann. Es macht die Sache für ihn nur komplizierter. Rot13 wäre ähnlich effektiv...

                            Na ok, wenn das auch nicht wirklich hilft.

                            Eine Frage: Warum sind die Versender überhaupt so hartnäckig? Kann man mit Deinem dollen Ding etwa Mails an Dritte versenden?

                            Im Prinzip ja.
                            Der Empfänger bin einerseits ich selber, andererseits erhält der Interessent eine Bestätigungsmail. Hierüber könnte Spam erzeugt werden.

                            Dann gilt die folgende, einfache Regel: Der Benutzer bestimmt entweder den Empfänger ODER (Subjekt oder jeglichen Inhalt) der Nachricht).

                            Ich fänd schon ganz nett, wenn der Interessent sein Interesse mittels Subject und message frei zum Ausdruck bringen könnte.
                            Im Zweifel lass ich einfach die Antwortmail weg, weil sie eh nur dem entspricht, was der Interessent auch auf der Webseite selber zu lesen bekommt.
                            Und einem Interessenten, der auch für mich interessant ist, antworte ich sowieso zeitnah.

                            Captcha:

                            • Hast Du sowas schon versucht?

                            Nein, verschon mich damit.
                            Ich selber bin so genervt ob jeder Art von Captcha, ich finde, dass muss anders gehen.

                            1. Eine Frage: Warum sind die Versender überhaupt so hartnäckig? Kann man mit Deinem dollen Ding etwa Mails an Dritte versenden?

                              Im Prinzip ja.
                              Der Empfänger bin einerseits ich selber, andererseits erhält der Interessent eine Bestätigungsmail. Hierüber könnte Spam erzeugt werden.

                              Heiße Herdplatte! Finger weg!

                              Da hast Du schneller Abmahner oder sogar Abmahngauner am Hals als Du denkst. Und kannst bei beharrlichem Festhalten an den kruden Versuchen sogar im Knast landen (in Hessen dann - als Zivilhäftling - auch zusammen mit Schwerstverbrechern im Hochsicherheitsknast, was seitens des „Rechtstaates“ flugs für „rechtmäßig“ erklärt wird, obwohl es das gewiss nicht ist.)

                              Zeig nur an, dass die Nachricht verarbeitet wurde und weise darauf hin, dass bei einer fehlenden Reaktion technischen Gründe vorliegen können, weshalb man auf andere Weise Kontakt suchen solle.

                    2. Hallo Raketenwilli,

                      truly

                      Truly Scrumptious 😀?

                      Das Wort heißt meines Wissens truthy, abgeleitet von truth. Analog zu falsy

                      Für Hank:

                      $name = $_POST['author'] ?? null;
                      if(is_null($name) || $name == '')

                      ließe sich wohl auch im if mit (empty($_POST['name'])) abhandeln. Im "Mail senden" Teil kann man dann vertrauensvoll $_POST['name'] verwenden (und je nach Mailformat mit htmlspecialchars oder anderen Maskierungscremes behandeln).

                      $email = $_POST['email'] ?? null;
                      is_null($email) || filter_var(...)

                      Analog:

                      if (!filter_input(INPUT_POST, 'mail', FILTER_VALIDATE_EMAIL)) {
                          // error
                      }
                      

                      Für beide:

                      (Token) - was aber auch zutrifft, wenn diese jeweils entweder leer, 0 oder false sind…

                      Die Frage mit dem $_SESSION['token'] != $_POST['token'] Vergleich ist so eine Sache. Eingangs wird isset($_SESSION['token']) geprüft, und wenn false, ein String hineingeschrieben. Sofern nicht anderswo im Code mit dem Token in der Session herummanipuliert wird, sollte das sicherstellen, dass $_SESSION['token'] nach dieser Abfrage einen String der Länge 64 enthält. Der != Test ist damit hinreichend. Eine !empty() statt is_set Abfrage wäre natürlich genauer, und !== wäre klarer. Aber auch so, wie es jetzt ist, müsste es schon ungepostete Teile des Server-Codes geben, die $_SESSION['token'] auf einen Leerstring oder null setzen, um den von RW genannten Fehlerfall zu bekommen.

                      Was mit $nur_ziffern_ausgefuellt ist, bleibt aber der sandgestrahlten Milchglaskugel überlassen.

                      Ich stimme Hank deshalb zu 99.9% zu: Wenn der Code bis zu diesem Test kommt, dann war das Token gültig. Entweder gültig von Browser submittet oder gültig von einem Bot, der hidden inputs kennt, gefaket.

                      Ist $nur_ziffern_ausgefuellt gesetzt, dann ist das entweder so, oder der Code, der diese Variable setzt, ist defekt. Das würde ich als nächstes prüfen.

                      Wenn tatsächlich ein Bot das Token senden kann, wäre wohl JavaScript als nächste Hürde aufzurichten (ein Script, das dem hidden token seinen value zuweist) - aber es gibt auch Bots, die Script entweder lesen oder sogar ausführen können. Für die braucht man dann eine Aufgabe, die Intelligenz voraussetzt und die der Absender erstmal lösen muss.

                      Rolf

                      --
                      sumpsi - posui - obstruxi
                      1. $name = $_POST['author'] ?? null;
                        if(is_null($name) || $name == '')

                        ließe sich wohl auch im if mit (empty($_POST['name'])) abhandeln.

                        Bist du das sicher?
                        Erkennt empty(), ob eine Variable zwar existent, aber leer ist?
                        Ich dachte immer, empty() vereint isset() und ob die Variable "false" ist.

                        1. Hallo Hank,

                          Nicht false. Falsy (oder falsey, wie das php Handbuch sagt).

                          Was für PHP false ist

                          Rolf

                          --
                          sumpsi - posui - obstruxi
                        2. Hello,

                          $name = $_POST['author'] ?? null;
                          if(is_null($name) || $name == '')

                          ließe sich wohl auch im if mit (empty($_POST['name'])) abhandeln.

                          Bist du das sicher?
                          Erkennt empty(), ob eine Variable zwar existent, aber leer ist?
                          Ich dachte immer, empty() vereint isset() und ob die Variable "false" ist.

                          Das Problem bei empty() ist, dass der String '0' aufgrund der automatischen Typumwandlung von PHP auch empty() ist. Damit ist empty() in den meisten Fällen unbrauchbar und man sollte es lieber diskret defineren, was man haben will. Das lässt sich später im Servicefall auch leichter lesen.

                          Ich bin ohnehin Feind von Kurzschreibweisen, wenn man mit ein paar mehr an Bytes ausgeschriebenem Code die Performance nicht merklich verschlechtert.

                          Wir hatten da aber auch schon das Gegenbeispiel mit den Regular Expressions, die immer schneller sind, als expliziter Code, wenn die RegEx-Engine innerhalb eines Skriptes mehrfach Verwendung findet.

                          Glück Auf
                          Tom vom Berg

                          --
                          Es gibt soviel Sonne, nutzen wir sie.
                          www.Solar-Harz.de
                          S☼nnige Grüße aus dem Oberharz
                      2. Hello,

                        Hallo Raketenwilli,

                        truly

                        Truly Scrumptious 😀?

                        Das Wort heißt meines Wissens truthy, abgeleitet von truth. Analog zu falsy

                        Ich kenne nur Trulli, mit Tomatensoße und Parmesan ;-)

                        BTW:

                        Man kann das Logging des Apachen auch so scharf schalten, dass er alles logged. Damit kann man derartige Planungen dann leichter kontrollieren. Darf man nachher nur nicht vergessen, wieder auf "normal" zurückzuschalten, sonst platzt die Platte.

                        Glück Auf
                        Tom vom Berg

                        --
                        Es gibt soviel Sonne, nutzen wir sie.
                        www.Solar-Harz.de
                        S☼nnige Grüße aus dem Oberharz
                2. Hello,

                  [...] da aber ein Programm bei identischen Daten und Einstellungen immer gleich reagiert [...]

                  Es sei denn, die dahinterliegende Hardware hat einen Glitch ;-P

                  Glück Auf
                  Tom vom Berg

                  --
                  Es gibt soviel Sonne, nutzen wir sie.
                  www.Solar-Harz.de
                  S☼nnige Grüße aus dem Oberharz
                  1. [...] da aber ein Programm bei identischen Daten und Einstellungen immer gleich reagiert [...]

                    Es sei denn, die dahinterliegende Hardware hat einen Glitch ;-P

                    Naja. Ich hatte neulich auch „foo.bar“ statt „foo bar“. Hardwarefehler: Der Punkt war ein angehustetes Krümel auf dem Monitor.

                    Aber das Programm, vorliegend auch der Computer hat bei identischen Daten und Einstellungen immer gleich reagiert.

                    … Wenn natürlich gleichzeitig ein Javascript namens rowhammer.js läuft… Aber das sollte sich bei der Performance bemerkbar machen.

    2. The dirty way: Nutze Output Buffering.

      Nein. Das ist keineswegs schmutzig, in halbwegs aktuellen PHP-Versionen ist das bei Debian & Co sogar so vorkonfiguriert. Allerdings sollte der TO aus $anderenGründen mal über Templates nachdenken, die ziehen das Aussenden jeglichen Contents erst nach Abarbeiten der eigentlichen Programmlogik nach sich.