[flohpapa]

Hallo, ich habe versucht das sessionbasierte Login Tutorial bei mir einzubinden.
Leider kommt nach dem Login immer :

Warning: Cannot modify header information - headers already sent by (output started at config.inc.php:20) in validateLogin.inc.php on line 76

             // Der Login war erfolgreich und der User wird zur Startseite des 
             // passwortgeschützen Bereichs weitergeleitet
             header( 'Location: geheim.php' );
             exit();

Kann mir irgendwer sagen woran das liegt?
Vielleicht seh ich grad den Wald vor lauter Bäumen nicht mehr.

[la-finest]

Diese Meldung kommt, wenn du mit echo oder print etwas ausgibst bevor du den header sendest. Sprich du hast irgendwo vor deinem header eine Ausgabe.
Vermutlich config.inc.php Zeile 20

Greetz.
la-finest

[flohpapa]

Ich find leider absolut keinen Fehler.
Kann jemand mal über den Code schauen? wär echt super.

PHP-Code:

<?php session_start();
    
    // Überprüfen, ob das Formular abgeschickt wurde und ob beide Angaben gemacht wurden.
    if( isset($_POST['username'], $_POST['passwort'])
        AND
        strcmp(trim($_POST['username']),'') != 0
        AND
        strcmp(trim($_POST['username']),'') != 0 ) {

          
          // Einbinden der Konfigurationsdatei
          include_once 'config.inc.php';
          
          // Erstellen der Verbindung zur MySQL-Datenbank 
          if( !$connection = mysql_connect( $_config['host'], $_config['user'], $_config['password'] ) ) {
               die( 'Verbindung zum Datenbankserver konnte nicht hergestellt werden.' );
          }

          if( !mysql_select_db( $_config['database'], $connection ) ) {
              die ( 'Die Datenbank ' . $_config['database'] . ' kann nicht verwendet werden. <br />
                       MySQL-Error: <br />' . mysql_error() );
          }
          
          
          // SQL-Anweisung an die Datenbank senden, um erstens herauszufinden, ob 
          // diese Kombination von Usernamen und Passwort überhaupt existiert und 
          // zweitens bei Existenz Userinformationen auszulesen
          $sql = "SELECT _id, _anzahlLogins FROM archiv_login WHERE _username = '".trim($_POST['username'])."' AND _passwort = '".md5(trim($_POST['passwort']))."'";
                           
          $res = mysql_query($sql) or die( 'Error[SELECT|User]: <br />
                                                           <pre>' . $sql . '</pre>
                                                           <br />
                                                           MySQL-Error: ' . mysql_error() );
              
          // Nur wenn genau ein Datensatz selektiert wurde wird der User eingeloggt.
          // In allen anderen Fällen wird er zurück zum Loginformular geleitet.
          if( mysql_num_rows($res) != 1 ) {
             header( 'Location: http://10.131.131.17/intranet/logintest/loginfehler.html' );              
             exit();
          } 
          else {
             // Der Schlüssel 'loggedIn' erhält den Wert 'true'. So kann überprüft später werden, 
             // ob der User eingeloggt ist oder nicht.
             $_SESSION['loggedIn'] = true;
             
             // Die userspezifischen Daten werden ausgelesen und der Session hinzugefügt
             $user = mysql_fetch_object($res);
             $_SESSION['anzahlLogins'] = $user->_anzahlLogins;
             $_SESSION['id'] = $user->_id;
             
             // Aktualisierung des Anzahl der Logins
             $sql = 'UPDATE 
                              archiv_login
                         SET
                              _anzahlLogins = _anzahlLogins + 1
                         WHERE
                              _id = ' . $user->_id;
                              
             mysql_query($sql) or die( 'Error[UPDATE|User]: <br />
                                                          <pre>' . $sql . '</pre>
                                                          <br />
                                                          MySQL-Error: ' . mysql_error() );  
                                                          
             // Der Login war erfolgreich und der User wird zur Startseite des 
             // passwortgeschützen Bereichs weitergeleitet
             header('Location:geheim.php');
             exit();                                            
          }
          
    }
    else {
          header( 'Location: index.html' );
          exit();
    } 

?>

und config.inc.php

PHP-Code:

<?php
    // Array initialisieren ...
    $_config = array();
    // ... und mit Werten füllen
    // Der Datenbankserver. 
    $_config['host'] = 'localhost';  
    // Ein User, der auf den Server zugreifen darf.
    $_config['user'] = 'root';        
    // Das zum User passende Passwort.
    $_config['password']  = 'root'; 
    // Der Name der Datenbank, die auf dem Datenbankserver angesprochen werden soll.
    $_config['database'] = 'test';
?>

[ads]

Ist Zeile 20 in config.inc.php zufällig nach dem schliessenden ?> Tag?
Dann wäre das eine ganz normale Ausgabe als HTML - und generiert Leerzeilen.

Nach dem schliessenden PHP-Tag darf sich maximal ein Zeilenumbruch befinden.

[flohpapa]

Oh man das Leerzeichen hätte ich nie gefunden.
Vielen Dank.
Und ich such mir nen Wolf.

[Jann Hendrik]

Naja - ist doch gut, wenn einem geholfen werden kann - und wenn man dadurch lernt sauber zu programmieren.

[Basti]

Den schließenden Tag kann man auch einfach weglassen.

Bastian

[Flor1an]

Richtig dass sollte man auch so machen! PHP bedarf keinem schließenden Tag (?>), außer man möchte natürlich noch HTML in dieser Datei ausgeben, sollte aber selten der Fall sein

Und ohne diesem schließenden Tag hat man eben nie das Problem das noch ein Leerzeichen am Ende existieren könnte!

[ads]

Die Diskussion "schließendes Tag" oder "nicht" ist wahrscheinlich fast so alt wie PHP - wenn nicht sogar noch älter.

Ursprünglich war PHP eine kleine Sprache, um mal eben etwas Funktionalität in die Webseite hineinzuverlagern. Mittlerweile ist das ganze jedoch umgedreht: viel PHP, wenig HTML - und immer noch alles gemischt. Nichtsdestotrotz ist das weglassen einfach unsauberes Programmieren: ich öffne ein Tag, also sollte ich es auch schließen. Die Vorteile, die sich aus dem Weglassen ergeben, sind dabei zweitrangig.

Nun, und wer es wirklich richtig machen will, trennt Code von Design und hat das Problem so auch erschlagen - und zwar sauber.

[Flor1an]

Zitat von ads

Nun, und wer es wirklich richtig machen will, trennt Code von Design und hat das Problem so auch erschlagen - und zwar sauber

Dabei kann es trotzdem passieren dass du hinter einem PHP Tag noch eine Leerzeile/Leerzeichen hast! Da ist egal ob HTML und PHP getrennt sind!

Im übrigen empfiehlt Zend selbst den closing Tag weg zu lassen.

[ads]

Zitat von Flor1an

Dabei kann es trotzdem passieren dass du hinter einem PHP Tag noch eine Leerzeile/Leerzeichen hast! Da ist egal ob HTML und PHP getrennt sind!

Richtig - Problem von PHP. Vernünftige Editoren zeigen das jedoch an.

Im übrigen empfiehlt Zend selbst den closing Tag weg zu lassen.

Ganz ehrlich?
Zuerst schreiben sie eine Programmiersprache, die "inline" arbeiten soll und dann kommen sie mit den Auswirkungen dieses Ansatzes nicht zurecht. Wenn es nicht so traurig wäre, könnte man ja lachen ...

Nur weil Zend das empfiehlt, ist das noch lange kein sauberer Programmierstil - ganz im Gegenteil.

[robo47]

Zitat von ads

Ganz ehrlich?

Guidelines fürs Zend-Framework:
http://framework.zend.com/manual/de/...atting.general

Zuerst schreiben sie eine Programmiersprache, die "inline" arbeiten soll und dann kommen sie mit den Auswirkungen dieses Ansatzes nicht zurecht. Wenn es nicht so traurig wäre, könnte man ja lachen ...

Nur weil Zend das empfiehlt, ist das noch lange kein sauberer Programmierstil - ganz im Gegenteil.

Naja, die Ursprünge von PHP liegen ja nicht bei Zend, Zend (bzw. die zwei Gründer) sind da erst später dazugekommen (ab PHP 3) und seit dem zeichnet ZEND für PHP verantwortlich.



Ich lasse den schließenden Tag übrigends mittlerweile auch immer weg.

[Jann Hendrik]

Für den Wunsch einer Diskussion zu der Thematik des abschließenden tags bitte hier eine Diskussion starten. Danke.

[Basti]

Zitat von ads

Nichtsdestotrotz ist das weglassen einfach unsauberes Programmieren: ich öffne ein Tag, also sollte ich es auch schließen. Die Vorteile, die sich aus dem Weglassen ergeben, sind dabei zweitrangig.

So? Was wäre denn der vorrangige Vorteil dieser Prinzipienreiterei? Du machst eine Tür, die von selbst wieder ins Schloss fällt doch auch nur dann zu, wenn du sicherstellen musst, dass sie dann auch wirklich geschlossen ist – solange du kein HTML in deinen PHP-Code verwurstest, dann musst du nie sicherstellen, dass ein PHP-Block wieder geschlossen wird.

Ich hab nichts gegen eine Erörterung der Vor- und Nachteile (obwohl mich diese Diskussion nicht interessieren würde), aber ein „weil es eben sauber ist, etwas zu schließen, was man geöffnet hat, obwohl es sich von selber schließt“ hat nichts mit sauberem Programmierstil zu tun. Damit schmeißt du auch gleich Hunderte oder Tausende von PHP-Entwicklern in den Topf, auf dem &#8222:pfuscher“ oder sowas steht. In den setze ich mich mitunter selber, aber nicht, weil ich meine schließenden PHP-Tags weglasse.

In dem Fall ziehe ich den Pragmatismus der Ästhetik eindeutig vor – und finde das wiederum ästhetisch.

Vielleicht hilft es, das <?php als Shebang interpretieren, um diesen Standpunkt zu verstehen.

Bastian