Gästebuch fertig! :-)

[KD-one]

Hi alle,

Da ich vorhabe, das Gästebuch zum kostenlosen Download bereitzustellen, ersuche ich euch Cracks nochmal, drüberzuschauen und mich auf ev. verbesserungsfähige Einzelheiten aufmerksam zu machen.
http://faq.united-web.at/guestbook/gaestebuch.phps
http://faq.united-web.at/guestbook/write.phps

Nochmals Danke an alle die mir beim Umbau weitergeholfen haben, wenn ich steckengeblieben bin.

Gruß

Kurt

[Raik]

Hallo, Kurt!

Da ich vorhabe, das Gästebuch zum kostenlosen Download bereitzustellen, ersuche ich euch Cracks nochmal, drüberzuschauen und mich auf ev. verbesserungsfähige Einzelheiten aufmerksam zu machen.

wenn du bei
     header(" ....
den pfad durch eine der server- oder php-variablen ersetzt (die den pfad enthalten), kann das script ohne änderungen von anderen verwendet werden. ich bin nur grad zu faul, rauszusuchen, welche variable das genau sein muss. ;-)

freundl. Grüsse aus Berlin, Raik

[KD-one]

Hi Raik,

Hallo, Kurt!

Da ich vorhabe, das Gästebuch zum kostenlosen Download bereitzustellen, ersuche ich euch Cracks nochmal, drüberzuschauen und mich auf ev. verbesserungsfähige Einzelheiten aufmerksam zu machen.

wenn du bei
     header(" ....
den pfad durch eine der server- oder php-variablen ersetzt (die den pfad enthalten), kann das script ohne änderungen von anderen verwendet werden. ich bin nur grad zu faul, rauszusuchen, welche variable das genau sein muss. ;-)

Du meinst einen Verweis auf das document_root?

Ich hatte sowieso vor, die Pfadangaben noch durch Variablen zu ersetzen, damit diese gesammelt am Anfang vom Nutzer editiert werden können, ohne in das Script selbst eingreifen zu müssen.

Gruß

Kurt

[Raik]

Hallo, KD-one!

Ich hatte sowieso vor, die Pfadangaben noch durch Variablen zu ersetzen, ...

gut.

... damit diese gesammelt am Anfang vom Nutzer editiert werden können, ohne in das Script selbst eingreifen zu müssen.

das kann das script doch selber:
    <?
    $path= str_replace($DOCUMENT_ROOT,$SERVER_NAME,$SCRIPT_FILENAME);
    echo 'http://'.substr($path, 0,strrpos($path,"/")+1);
    ?>
noch den namen des aufzurufenden scripts dazu und du hast den absoluten pfad für header("location: ...

freundl. Grüsse aus Berlin, Raik

[KD-one]

Hi Raik,

das kann das script doch selber:
    <?
    $path= str_replace($DOCUMENT_ROOT,$SERVER_NAME,$SCRIPT_FILENAME);
    echo 'http://'.substr($path, 0,strrpos($path,"/")+1);
    ?>
noch den namen des aufzurufenden scripts dazu und du hast den absoluten pfad für header("location: ...

Das schaut gut aus, solangeder Pfad übereinstimmt. Das ist bei mir aber nicht der Fall, die Gästebuch wird im Webroot mir GET-Parametern eingefügt, die URL entspricht nicht dem Pfad.
Aber für andere ist das sicherlich brauchbar, ich behalte diese Info als Option.

Danke.

Gruß

Kurt

[Raik]

Hallo, Kurt!

... die URL entspricht nicht dem Pfad.

sondern???
mod_rewrite? *grübel*

freundl. Grüsse aus Berlin, Raik

[KD-one]

Hi Raik,

... die URL entspricht nicht dem Pfad.

sondern???
mod_rewrite? *grübel*

freundl. Grüsse aus Berlin, Raik

URL: http://faq.united-web.at/index.php?body=1&content=guestbook
Pfad: http://faq.united-web.at/guestbook/gaestebuch.php

d.h., saämtliche Seiten linken auf die index.php zuzüglich der GET-Parameter.

Gruß

Kurt

[Der Gästebuchterminator]

Da ich vorhabe, das Gästebuch zum kostenlosen Download bereitzustellen,

Geil!

ersuche ich euch Cracks nochmal, drüberzuschauen und mich auf ev. verbesserungsfähige Einzelheiten aufmerksam zu machen.

Keine, vollkommen perfekt! Ganz besonders toll finde ich ja

http://faq.united-web.at/guestbook/write.phps

Da kann man so richtig Spaß haben!

$file = fopen('speicher.dat','r');
  [..]
  $homepage = '<a href="'.$url.'">'.$url.'</a>';
  [..]
  $nachricht_table ='<br>
  [..]
                     <tr><td style="text-align:right;">Homepage:</td>
                     <td style="text-align:left;" colspan="2">'.$homepage.'</td></tr>
  [..]
  fputs($file,"$nachricht_table \n $buffer");

Ich muss allerdings anmerken, dass Du vergessen hast, $url den Inhalt von $_POST["url"] zuzuweisen, ebenso bei $email.

Aber trotzdem, in Zusammenhang mit

http://faq.united-web.at/guestbook/gaestebuch.phps

@readfile('guestbook/speicher.dat');

öffnest Du den Kreativen unter uns ungeahnte Gestaltungsmöglichkeiten. Danke! So soll es sein! Wo kann ich das benutzen? Ich bin schon ganz wuschig!

Der Gästebuchterminator

[KD-one]

Hi Terminator,

ersuche ich euch Cracks nochmal, drüberzuschauen und mich auf ev. verbesserungsfähige Einzelheiten aufmerksam zu machen.

Keine, vollkommen perfekt! Ganz besonders toll finde ich ja

http://faq.united-web.at/guestbook/write.phps

Da kann man so richtig Spaß haben!

$file = fopen('speicher.dat','r');
  [..]
  $homepage = '<a href="'.$url.'">'.$url.'</a>';
  [..]
  $nachricht_table ='<br>
  [..]
                     <tr><td style="text-align:right;">Homepage:</td>
                     <td style="text-align:left;" colspan="2">'.$homepage.'</td></tr>
  [..]
  fputs($file,"$nachricht_table \n $buffer");

Ich muss allerdings anmerken, dass Du vergessen hast, $url den Inhalt von $_POST["url"] zuzuweisen, ebenso bei $email.

Ja, stimmt. *schäm*
Das ändere ich sofort.

Aber trotzdem, in Zusammenhang mit

http://faq.united-web.at/guestbook/gaestebuch.phps

@readfile('guestbook/speicher.dat');

*lol*
Ich find es lustig, daß du so humorvoll auf meine Fehler reagierst. :-)
Deshalb auch dieses Posting, um Schwachstellen aufzudecken, damit ich das vorher noch ändern kann.
Es ist halt so, als Anfänger stolpert man über Sachen, die einem Profi nie passieren würden.
Da ich das aber einfach als Hobby betreibe und keinerlei Anspruch auf Professionalität erhebe, wollte ich mich vorher nochmal vergewissern, daß ich mit em Script keine Scheunentore aufreisse.

Ach ja, zu deiner Anspielung: Welche Sicherheitsbedenken bewegen dich im Zusammenhang mit "@readfile('guestbook/speicher.dat');"?

öffnest Du den Kreativen unter uns ungeahnte Gestaltungsmöglichkeiten. Danke! So soll es sein! Wo kann ich das benutzen? Ich bin schon ganz wuschig!

Lieber noch nicht. Später vielleicht, nachdem du mir geholfen hast, die Löcher zu stopfen. :-P

Gruß

Kurt

[Der Gästebuchterminator]

öffnest Du den Kreativen unter uns ungeahnte Gestaltungsmöglichkeiten. Danke! So soll es sein! Wo kann ich das benutzen? Ich bin schon ganz wuschig!

Lieber noch nicht. Später vielleicht, nachdem du mir geholfen hast, die Löcher zu stopfen. :-P

Nein! Nein!! Niemals!!! Ich möchte mir doch nicht die Möglichkeit nehmen lassen, mit ein wenig eigenem HTML-, Javascript- und CSS-Code das Gästebuch zu verschönern! Oder meine Dialer unters gierige Volk zu bringen!! Meine Kreditkartennummernauspürschnüffelprogramme!!! Wo Du doch alles, was in $url landet, so freundlich in den Quellcode der Gästebuchseite übernimmst, lässig geschickt die Nutzung von htmlentities() umschiffend. Niemals!

Der Gästebuchterminator

[KD-one]

Hi Terminator,

Lieber noch nicht. Später vielleicht, nachdem du mir geholfen hast, die Löcher zu stopfen. :-P

Nein! Nein!! Niemals!!! Ich möchte mir doch nicht die Möglichkeit nehmen lassen, mit ein wenig eigenem HTML-, Javascript- und CSS-Code das Gästebuch zu verschönern! Oder meine Dialer unters gierige Volk zu bringen!! Meine Kreditkartennummernauspürschnüffelprogramme!!! Wo Du doch alles, was in $url landet, so freundlich in den Quellcode der Gästebuchseite übernimmst, lässig geschickt die Nutzung von htmlentities() umschiffend. Niemals!

Boah, eh, das ist wahrlich ein Black Hole, das ich mir da unvorsichtigerweise aufgerissen habe. Ich werde mich gleich heute abend dransetzen und es verbessern.
Apropos, ist die Problematik bei Verwendung von $_POST['url'] ebensogroß?
Das zumindest habe ich sofort geändert.

Gruß

Kurt

[Badboy46]

Hallo

Apropos, ist die Problematik bei Verwendung von $_POST['url'] ebensogroß?

http://de3.php.net/function.htmlspecialchars würde ich auf jeden Fall drüber laufen lassen

[KD-one]

Hi Badboy46,

Ja, da muss ich mich aber erst mal einlesen.
Hätte nicht gedacht, daß ich soviel übersehen habe. :-/

Gruß

Kurt

[Badboy46]

Hallo

öffnest Du den Kreativen unter uns ungeahnte Gestaltungsmöglichkeiten. Danke! So soll es sein! Wo kann ich das benutzen? Ich bin schon ganz wuschig!

versuch es doch mal da

http://faq.united-web.at/index.php?body=1&content=guestbook
der Link steht doch in der write.php ;-)

[KD-one]

Hi Badboy46,

versuch es doch mal da

http://faq.united-web.at/index.php?body=1&content=guestbook
der Link steht doch in der write.php ;-)

Nö, iss ein netter Terminator, er lässt mir noch Zeit, mich selbst zu terminieren. :o)

Gruß

Kurt

[Sven Rautenberg]

Moin!

Ich geh mal auf das ein, was mir seltsam vorkommt:

http://faq.united-web.at/guestbook/write.phps

$tname = trim($_POST['name']);
$tnachricht = trim($_POST['nachricht']);
if ((isset($_POST['name']) && empty($tname)) || (isset($_POST['nachricht']) && empty($tnachricht)))

Das ist widersinnig. Wenn $_POST['name'] nicht isset ist, dann fliegt dir bei error_reporting E_ALL die Zuweisung an $tname bzw. $tnachricht um die Ohren.

Und zweitens: Wenn schon die Zuweisung an neue Variablen, warum dann nicht auch isset auf diese anwenden?

else if (isset($_POST['submit']) && $_POST['submit'] == 'eintragen')

Da du vor dem else die Verarbeitung des Skriptes komplett abbrichst und einen Redirect aussprichst, ist das else sowieso nicht mehr notwendig. Spart dir Klammerebenen ein, zumindest aber logische Abhängigkeiten, die keine sind. Und das hier ist keine.

Zu bemängeln ist, dass die getätigten Eingaben im Formular bei der Fehlermeldung komplett verloren gehen. Bei einem Namen ist das sicher nicht so schlimm (wenn der Kommentar fehlt), umgekehrt aber schon. Mache ein Affenformular da hin!

if(!eregi('^([a-z0-9.\_-]+)@([a-zäöü0-9.-]+.[a-z]{2,6})$',$email))

Naja, über die Sinnhaftigkeit einfacher regulärer Ausdrücke zur Prüfung von EMail-Adressen wurde hier (auch von mir) schon viel geschrieben. Dein Versuch, die neuen Umlautdomains zu berücksichtigen, kann nur als halbherzig gewertet werden. "äöü" sind nur drei von insgesamt über 50 neuen Zeichen, die in .de, .at und .ch neu in Domainnamen vorkommen dürfen. Weltweit sind allerdings grundsätzlich die meisten Unicode-Buchstaben erlaubt (insbesondere Chinesisch - deswegen gibts doch den ganzen Zirkus überhaupt) - real hängt der Umfang von den Bedingungen der TLD-Verwalter ab! Damit hat sich ein regulärer Ausdruck sowieso erledigt, weil du kaum alle Bedingungen immer auf dem aktuellen Stand halten kannst - geschweige denn sie recherchieren.

Deshalb mein guter Rat: Eine Mailadresse, der man von überall her schreiben kann, besteht aus: Mindestens einem Zeichen, einem @, mindestens einem Zeichen, einem Punkt, und mindestens zwei Zeichen, die kein Punkt sind. Oder in Kurz: In der Mailadresse kommt ein @ und danach mindestens ein Punkt vor, alles andere ist garantiert keine gültige Mailadresse. Und alles, was durchkommt, kann auch falsch sein, aber ohne dass du weitere Realitätsprüfungen (Befragen des DNS-Systems, Kontakten des angeblichen Mailservers, Versandversuch einer Mail an den Empfänger) durchführst, wirst du sowieso keine nennenswerte Verbesserung der Eingaben erzielen.

Und noch ein weiteres Problem tritt auf: Eigentlich müsstest du die Maildomain mit Sonderzeichen auch noch Punycode-codieren und dann gucken, ob da eine gültige normale Domain bei rauskommt. Denn es gibt tatsächlich Domains mit ungültigen Sonderzeichen. Das "ß" beispielsweise wird im Codierungsprozess zu "ss" - und das Resultat ist: Es gibt keine Domain "www.weiß.de" und auch kein Punycode-Äquivalent "www.xn-weiss.de", weil sie "www.weiss.de" entsprechen muß.

Die Problematik der Code-Injection hat dir der Gästebuchterminator schon verdeutlicht - dazu nur eine Anmerkung: strip_tags() ist KEINE vernünftige Alternative zu htmlspecialchars(). strip_tags() löscht je nach Problemfall entweder zuwenig (böse und gefährlich!) oder zuviel (böse und ärgerlich!).

- Sven Rautenberg

[Badboy46]

Hallo

Die Problematik der Code-Injection hat dir der Gästebuchterminator schon verdeutlicht - dazu nur eine Anmerkung: strip_tags() ist KEINE vernünftige Alternative zu htmlspecialchars(). strip_tags() löscht je nach Problemfall entweder zuwenig (böse und gefährlich!) oder zuviel (böse und ärgerlich!).

bei mir hat diese Funktion noch nie zu viel entfernt
kannst du mal Beispiele nennen?

mann könnte ja auch erst strip_tags() drüber laufen lassen und dann zum Schluss noch mit htmlentities($text,ENT_QUOTES).

[Sven Rautenberg]

Moin!

bei mir hat diese Funktion noch nie zu viel entfernt
kannst du mal Beispiele nennen?

Zum einen: strip_tags hat eine lange Historie an Bugs, die so nach und nach entfernt wurden. Die Funktion taucht ziemlich häufig in http://www.php.net/ChangeLog-4.php auf, und da nicht alle Provider immer sofort die neueste PHP-Version draufspielen, kann man da schön in Teufels Küche kommen.

In http://forum.de.selfhtml.org/archiv/2004/1/t69076/#m397584 ist nur eines der Probleme beschrieben.

Und für dich zum Testen:
<?php

$test = "Es gilt 2<3 und 3>1.";
$test2 = strip_tags($test);

echo "Test: ".htmlspecialchars($test)."<br>";
echo "Test2: ".htmlspecialchars($test2)."<br>";
echo "PHP: ".PHP_VERSION;

?>

Das führt bei mir zu:
Test: Es gilt 2<3 und 3>1.
Test2: Es gilt 21.
PHP: 4.3.6

Und DAS ist NICHT GUT.

- Sven Rautenberg

[Badboy46]

Hallo

Und für dich zum Testen:
<?php

$test = "Es gilt 2<3 und 3>1.";
$test2 = strip_tags($test);

echo "Test: ".htmlspecialchars($test)."<br>";
echo "Test2: ".htmlspecialchars($test2)."<br>";
echo "PHP: ".PHP_VERSION;

?>

bei mir kommt

Test: Es gilt 2<3 und 3>1.
Test2: Es gilt 21.
PHP: 4.3.7

gibt es denn eine andere Möglichleit <b><i> <p ...> etc. rauszufiltern?

[Sven Rautenberg]

Moin!

bei mir kommt

Test: Es gilt 2<3 und 3>1.
Test2: Es gilt 21.
PHP: 4.3.7

gibt es denn eine andere Möglichleit <b><i> <p ...> etc. rauszufiltern?

Ist doch die Frage, warum man das rausfiltern muß? Wer in einer Textarea ein "<"-Zeichen eingibt, der will das offenbar als Text auch wieder ausgegeben kriegen. Ergo: htmlspecialchars() drüberlaufen lassen, und alles ist paletti.

Dass ein Gästebucheintrag etwas doof aussieht, wenn HTML-Quellcode sichtbar drinsteht, gebe ich zwar zu, aber das ist immer noch besser, als ungewollt Text zu schlucken. Und man muß sein Gästebuch ja sowieso administrieren.

Wenn man gewisse Gestaltungsmöglichkeiten erlauben will, kann man BB-Code nutzen (eine entsprechende PHP-Klasse von Christian Seiler existiert -> Archivsuche), oder gewisse, explizit benannte HTML-Tags ganz gesondert behandeln (die also nach htmlspecialchars() wieder raussuchen und in HTML-Tags umwandelt. str_replace("&lt;b&gt;","<b>",....)

- Sven Rautenberg

[KD-one]

Hi Sven,

Moin!

Ich geh mal auf das ein, was mir seltsam vorkommt:

http://faq.united-web.at/guestbook/write.phps

$tname = trim($_POST['name']);
$tnachricht = trim($_POST['nachricht']);
if ((isset($_POST['name']) && empty($tname)) || (isset($_POST['nachricht']) && empty($tnachricht)))

Das ist widersinnig. Wenn $_POST['name'] nicht isset ist, dann fliegt dir bei error_reporting E_ALL die Zuweisung an $tname bzw. $tnachricht um die Ohren.

Stimmt, das habe ich nicht bedacht, als ich das Script trennte.

Und zweitens: Wenn schon die Zuweisung an neue Variablen, warum dann nicht auch isset auf diese anwenden?

else if (isset($_POST['submit']) && $_POST['submit'] == 'eintragen')

Da du vor dem else die Verarbeitung des Skriptes komplett abbrichst und einen Redirect aussprichst, ist das else sowieso nicht mehr notwendig. Spart dir Klammerebenen ein, zumindest aber logische Abhängigkeiten, die keine sind. Und das hier ist keine.

Stimmt auch, da hab ich aber doch noch einiges übersehen.

Zu bemängeln ist, dass die getätigten Eingaben im Formular bei der Fehlermeldung komplett verloren gehen. Bei einem Namen ist das sicher nicht so schlimm (wenn der Kommentar fehlt), umgekehrt aber schon. Mache ein Affenformular da hin!

Was meinst du mit Affenformular???

if(!eregi('^([a-z0-9.\_-]+)@([a-zäöü0-9.-]+.[a-z]{2,6})$',$email))

Naja, über die Sinnhaftigkeit einfacher regulärer Ausdrücke zur Prüfung von EMail-Adressen wurde hier (auch von mir) schon viel geschrieben. Dein Versuch, die neuen Umlautdomains zu berücksichtigen, kann nur als halbherzig gewertet werden. "äöü" sind nur drei von insgesamt über 50 neuen Zeichen, die in .de, .at und .ch neu in Domainnamen vorkommen dürfen. Weltweit sind allerdings grundsätzlich die meisten Unicode-Buchstaben erlaubt (insbesondere Chinesisch - deswegen gibts doch den ganzen Zirkus überhaupt) - real hängt der Umfang von den Bedingungen der TLD-Verwalter ab! Damit hat sich ein regulärer Ausdruck sowieso erledigt, weil du kaum alle Bedingungen immer auf dem aktuellen Stand halten kannst - geschweige denn sie recherchieren.

Deshalb mein guter Rat: Eine Mailadresse, der man von überall her schreiben kann, besteht aus: Mindestens einem Zeichen, einem @, mindestens einem Zeichen, einem Punkt, und mindestens zwei Zeichen, die kein Punkt sind. Oder in Kurz: In der Mailadresse kommt ein @ und danach mindestens ein Punkt vor, alles andere ist garantiert keine gültige Mailadresse. Und alles, was durchkommt, kann auch falsch sein, aber ohne dass du weitere Realitätsprüfungen (Befragen des DNS-Systems, Kontakten des angeblichen Mailservers, Versandversuch einer Mail an den Empfänger) durchführst, wirst du sowieso keine nennenswerte Verbesserung der Eingaben erzielen.

Ja, da hast du recht, ich werde mir mal eine etwas einfachere Variante zusammenschustern.

Und noch ein weiteres Problem tritt auf: Eigentlich müsstest du die Maildomain mit Sonderzeichen auch noch Punycode-codieren und dann gucken, ob da eine gültige normale Domain bei rauskommt. Denn es gibt tatsächlich Domains mit ungültigen Sonderzeichen. Das "ß" beispielsweise wird im Codierungsprozess zu "ss" - und das Resultat ist: Es gibt keine Domain "www.weiß.de" und auch kein Punycode-Äquivalent "www.xn-weiss.de", weil sie "www.weiss.de" entsprechen muß.

Die Problematik der Code-Injection hat dir der Gästebuchterminator schon verdeutlicht - dazu nur eine Anmerkung: strip_tags() ist KEINE vernünftige Alternative zu htmlspecialchars(). strip_tags() löscht je nach Problemfall entweder zuwenig (böse und gefährlich!) oder zuviel (böse und ärgerlich!).

Ja, ich fürchte, dieses Kapitel habe ich insgesamt zuwenig bedacht und berücksichtigt, da werd ich wohl oder übel noch mal ran müssen.
Ich danke dir für deine Analyse.

Gruß

Kurt

[Sven Rautenberg]

Moin!

Zu bemängeln ist, dass die getätigten Eingaben im Formular bei der Fehlermeldung komplett verloren gehen. Bei einem Namen ist das sicher nicht so schlimm (wenn der Kommentar fehlt), umgekehrt aber schon. Mache ein Affenformular da hin!

Was meinst du mit Affenformular???

http://www.dclp-faq.de/q/q-stil-normalform.html

- Sven Rautenberg

[Badboy46]

Hallo

Zu bemängeln ist, dass die getätigten Eingaben im Formular bei der Fehlermeldung komplett verloren gehen. Bei einem Namen ist das sicher nicht so schlimm (wenn der Kommentar fehlt), umgekehrt aber schon. Mache ein Affenformular da hin!

Was meinst du mit Affenformular???

http://www.dclp-faq.de/q/q-stil-normalform.html

warum nennt man das eigentlich Affenformular?
das hört sich so an, als ob es der letzte Scheiss ist ;)

Es heißt Affenformular, weil eine Million Affen dieses Formular eine Million mal aufrufen können, ohne etwas zu bewirken.

dann müssen ja normale HTML-Seiten auch Affenseiten heissen ;-)
da passiert auch nix, wenn man die eine Million mal aufruft ^^

[Sven Rautenberg]

Moin!

warum nennt man das eigentlich Affenformular?

"If you have enough monkeys banging randomly on typewriters, they will eventually type the works of William Shakespeare."

Bei diesem Spruch würde ich das einordnen. :)

das hört sich so an, als ob es der letzte Scheiss ist ;)

Nicht Scheiss - Schrei! :)

dann müssen ja normale HTML-Seiten auch Affenseiten heissen ;-)
da passiert auch nix, wenn man die eine Million mal aufruft ^^

Manche Seiten sind tatsächlich affig. ;)

- Sven Rautenberg

[Badboy46]

Hallo

warum nennt man das eigentlich Affenformular?

"If you have enough monkeys banging randomly on typewriters, they will eventually type the works of William Shakespeare."

Bei diesem Spruch würde ich das einordnen. :)

das hört sich so an, als ob es der letzte Scheiss ist ;)

Nicht Scheiss - Schrei! :)

ist/soll dieses Verfahren nun schlecht sein?

[Sven Rautenberg]

Moin!

das hört sich so an, als ob es der letzte Scheiss ist ;)

Nicht Scheiss - Schrei! :)

ist/soll dieses Verfahren nun schlecht sein?

Nein, ein Affenformular ist definitiv das anzuratende Vorgehen bei Formularverarbeitung, sofern man als Programmierer die Daten serverseitig prüft und bei falchen oder fehlenden Daten den Benutzer darauf hinweisen und zur Nacherhebung bitten muß.

Der klassische Formmailer für Kontaktmails, bei denen es eigentlich auf absolut gar keine Information ankommt (ein leeres Formular schickt dann eben eine ziemlich leere Mail an den Empfänger), erfordert natürlich kein Affenformular.

Aber sobald man beispielsweise fordert, dass eine eigene Mailadressen angegeben werden muß, und man diese Mailadresse auch irgendwie prüft und falche Adressen zurückweist, ist ein Affenformular definitiv angesagt. Denn es ist schon blöd, wenn man so ein Kontaktformular hat, und jemand einen hilfreichen Hinweis (z.B. Link falsch etc. - das geht ja auch anonym) geben will - und das Formular meckert über eine fehlende Mailadresse, und der geschriebene Hinweistext ist dann weg. Wie wahrscheinlich ist dann, dass der Besucher den nochmal eintippt?

- Sven Rautenberg

[KD-one]

Hi Sven,

Zu bemängeln ist, dass die getätigten Eingaben im Formular bei der Fehlermeldung komplett verloren gehen. Bei einem Namen ist das sicher nicht so schlimm (wenn der Kommentar fehlt), umgekehrt aber schon. Mache ein Affenformular da hin!

Was meinst du mit Affenformular???

http://www.dclp-faq.de/q/q-stil-normalform.html

Oh, danke für den Link!
Aber: Mit $_SERVER["PHP_SELF"] ruft sich ja das Formular immer wieder selbst auf.
Wenn ich nun mit diesem Action-Attribut die Prüfung durchführe und danach bei erfolgreicher Prüfung auf die eigentliche Verarbeitungsdatei weiterleite?

So in etwa hab ich mir das vorgestellt:
if((!empty($error["name"]) || !empty($error["nachricht"])) {
    echo $error;
} else {
    header( "location:http://...");
    exit;
}
?>

Komm ich da mit meinen Überlegungen hin, oder ist ein Fehler drin?
Es sollen natürlich bei erfolgreichem Eintragen die Felder nicht mehr gefüllt werden, um unabsichtliche Mehrfachpostings auszuschliessen.

Gruß

Kurt

[Sven Rautenberg]

Moin!

Oh, danke für den Link!
Aber: Mit $_SERVER["PHP_SELF"] ruft sich ja das Formular immer wieder selbst auf.

Ja und?

Entscheidend ist doch: Das Formular wird abgeschickt, und in Abhängigkeit von den gemachten Eingaben kommt garantiert irgendeine neue HTML-Seite zum Vorschein. Deren URL ist zweitrangig.

Der Vorteil des Affenformulars ist, dass du in der Grundform ohne weitere Funktionalität die Formulareingaben immer wieder in einem neuen Formular als vorausgefüllten Text zurückkriegst.

Dein jetziges System hat eben den Nachteil, dass du die Formularinformationen zuerst zu deinem Prüfskript übermittelst. Dort stellst du dann fest, dass irgendwas nicht stimmt - und leitest nur einen Fehlercode weiter (bzw. "zurück) zur erneuten Formularseite. Die gemachten Formulareingaben aber gehen verloren.

Wenn ich nun mit diesem Action-Attribut die Prüfung durchführe und danach bei erfolgreicher Prüfung auf die eigentliche Verarbeitungsdatei weiterleite?

Warum dies? Du prüfst ganz oben im einzigen PHP-Skript (dem mit dem Affenformular), ob die Bedingungen für einen gültigen Gästebucheintrag erfüllt sind. Wenn dies der Fall ist, trägst du die Daten in die Datei ein, speicherst sie, und leitest dann zurück auf irgendeine Seite mit z.B. der Ausgabe des vollständigen Gästebuchs. Weiterleitungen mit header() sind in diesem Falle gut, weil du damit das Reload-Problem umgehst.

Wenn am Formular aber irgendwas auszusetzen ist, kommt ein ELSE zum Tragen. Und dieses ELSE ist dein Affenformular. Das bedeutet: Beim Erstaufruf gibts kein $_POST, also muß auch nichts angemeckert werden, sondern es kommt direkt das Formular. Wenn aber was abgeschickt wurde, existiert Inhalt in $_POST, der dann, wenn ELSE dran ist, nicht korrekt war, also mit einem Kommentar (welcher, wurde vorher festgelegt) angemeckert wird, und der ungültige Inhalt von $_POST wird in die Formularfelder zurückgefüllt, damit der Benutzer Informationen nachtragen kann.

Nur auf diese Weise kriegst du eine gute Benutzerfreundlichkeit hin. Denn bis auf Opera haben irgendwie (mein Eindruck kann bei Mozilla/Firefox auch täuschen) alle Browser Probleme, bei Formularseiten von der "Es fehlt was!"-Meckerseite zurückzublättern und den schon mal abgeschickten Formularinhalt wieder anzuzeigen. Meist ist das Formular dann wieder komplett leer, so wie es beim ersten Mal vom Server geladen wurde.

Es sollen natürlich bei erfolgreichem Eintragen die Felder nicht mehr gefüllt werden, um unabsichtliche Mehrfachpostings auszuschliessen.

Wie gesagt: Mehrfachpostings durch unabsichtliches Reload verhindert man durch ein Redirect von der POST-Ergebnisseite. Ein geglücktes POST-Formular erzeugt also keine eigene Danke-Seite (oder was da sonst so drauf stehen mag), sondern leitet zu einer Danke-Seite weiter. Das kann auch wieder dasselbe Skript sein, welches mit einem Parameter dann in einen dritten Zweit geht und nur "Danke" ausgibt - oder eben zurück auf Null geht und das Gästebuch (inkl. des neuen Postings) sowie das leere Formular ausgibt - genauso wie beim ersten Aufruf.

Trenne dich mal gedanklich von der Vorstellung, dass ein PHP-Skript exakt EINE einzige Aufgabe erfüllen darf. Das ist in der Regel eine eher ungünstige Aufgabenteilung, wenn man beim Aufruf einer URL noch nicht zwingend weiß, was man dem User denn mitteilen will, sondern das von den gesendeten Daten abhängig machen muß.

- Sven Rautenberg

[KD-one]

Hi Sven,

So, nun hab ich mir dein Posting dreimal durchgelesen, bis ich draufgekommen bin, was du meinst. ;-)

Der Vorteil des Affenformulars ist, dass du in der Grundform ohne weitere Funktionalität die Formulareingaben immer wieder in einem neuen Formular als vorausgefüllten Text zurückkriegst.

Dein jetziges System hat eben den Nachteil, dass du die Formularinformationen zuerst zu deinem Prüfskript übermittelst. Dort stellst du dann fest, dass irgendwas nicht stimmt - und leitest nur einen Fehlercode weiter (bzw. "zurück) zur erneuten Formularseite. Die gemachten Formulareingaben aber gehen verloren.

Stimmt, erst aufgrund des gelieferten Fehlecodes kann ich entscheiden, welche Nachricht ausgegeben werden soll.

Wenn ich nun mit diesem Action-Attribut die Prüfung durchführe und danach bei erfolgreicher Prüfung auf die eigentliche Verarbeitungsdatei weiterleite?

Warum dies? Du prüfst ganz oben im einzigen PHP-Skript (dem mit dem Affenformular), ob die Bedingungen für einen gültigen Gästebucheintrag erfüllt sind. Wenn dies der Fall ist, trägst du die Daten in die Datei ein, speicherst sie, und leitest dann zurück auf irgendeine Seite mit z.B. der Ausgabe des vollständigen Gästebuchs. Weiterleitungen mit header() sind in diesem Falle gut, weil du damit das Reload-Problem umgehst.

Und genau daran hab ich mich aufgehängt, bis ich auf die Idee kam, daß ich ja, im Falle eines erfolgreichen Abschickens, dieselbe Seite mit header() wieder aufrufen könnte. In dem Falle würden ja die Daten nicht wieder eingefügt, da die Seite neu geladen wird.
Hab ich das nun richtig verstanden?

Wenn am Formular aber irgendwas auszusetzen ist, kommt ein ELSE zum Tragen. Und dieses ELSE ist dein Affenformular. Das bedeutet: Beim Erstaufruf gibts kein $_POST, also muß auch nichts angemeckert werden, sondern es kommt direkt das Formular. Wenn aber was abgeschickt wurde, existiert Inhalt in $_POST, der dann, wenn ELSE dran ist, nicht korrekt war, also mit einem Kommentar (welcher, wurde vorher festgelegt) angemeckert wird, und der ungültige Inhalt von $_POST wird in die Formularfelder zurückgefüllt, damit der Benutzer Informationen nachtragen kann.

Dazu noch eine, nein, zwei Fragen:
Kristian Köhntopp verwendet in seinem Beispielformular $_REQUEST anstatt $_POST. Gibt es dafür einen besonderen Grund?
Laut http://www.php.net/manual/de/language.variables.predefined.php sind die darin enthaltenen Daten nicht vertrauenswürdig.
Und zweitens verwendet er anstatt dem Echo-Befehl "print", was imho dasselbe bewirkt.
Steckt da etwa eine Funktionalität dahinter, den ich (noch) nicht realisiert habe?

Nur auf diese Weise kriegst du eine gute Benutzerfreundlichkeit hin. Denn bis auf Opera haben irgendwie (mein Eindruck kann bei Mozilla/Firefox auch täuschen) alle Browser Probleme, bei Formularseiten von der "Es fehlt was!"-Meckerseite zurückzublättern und den schon mal abgeschickten Formularinhalt wieder anzuzeigen. Meist ist das Formular dann wieder komplett leer, so wie es beim ersten Mal vom Server geladen wurde.

Auf alle Fälle ist es am benutzerfreundlichsten, wenn im Fehlerfalle die ausgefüllte Seite wieder erscheint, ohne blättern zu müssen.

Wie gesagt: Mehrfachpostings durch unabsichtliches Reload verhindert man durch ein Redirect von der POST-Ergebnisseite. Ein geglücktes POST-Formular erzeugt also keine eigene Danke-Seite (oder was da sonst so drauf stehen mag), sondern leitet zu einer Danke-Seite weiter. Das kann auch wieder dasselbe Skript sein, welches mit einem Parameter dann in einen dritten Zweit geht und nur "Danke" ausgibt - oder eben zurück auf Null geht und das Gästebuch (inkl. des neuen Postings) sowie das leere Formular ausgibt - genauso wie beim ersten Aufruf.

Damit ich sicher bin: Hast du nun davon gesprochen, was ich oben schon angedeutet habe? Nämlich auf dieselbe Seite weiterzuleiten, wobei ich dann keine ausgefüllten Formularfelder mehr erhalte?

Trenne dich mal gedanklich von der Vorstellung, dass ein PHP-Skript exakt EINE einzige Aufgabe erfüllen darf. Das ist in der Regel eine eher ungünstige Aufgabenteilung, wenn man beim Aufruf einer URL noch nicht zwingend weiß, was man dem User denn mitteilen will, sondern das von den gesendeten Daten abhängig machen muß.

Auf alle Fälle mal ein herzliches Dankeschön. Ich werde mir mal ein Testformular zusammenbauen und die Funktionalität austesten, bis ich wirklich alle Vorgänge kapiert habe.
Danke!

Gruß

Kurt

[Sven Rautenberg]

Moin!

Dazu noch eine, nein, zwei Fragen:
Kristian Köhntopp verwendet in seinem Beispielformular $_REQUEST anstatt $_POST. Gibt es dafür einen besonderen Grund?

Bequemlichkeit, den User in einer FAQ nicht noch mit tausend anderen Details zu quälen, würde ich vermuten.

In $_REQUEST stehen halt $_POST und $_GET drin - das zu verwenden spart dann dumme Anfragen von Total-DAUs, die es nicht gebacken kriegen, den Beispielcode sachgerecht von POST auf GET umzustellen, weil sie nur das Attribut method im <form> ändern.

Ich persönlich verwende $_REQUEST nie.

Laut http://www.php.net/manual/de/language.variables.predefined.php sind die darin enthaltenen Daten nicht vertrauenswürdig.

Naja, das gilt für die Tatsache, dass eben $_GET, $_POST und $_COOKIES gemischt werden. Alles drei sind User-Informationen, denen man sowieso mißtrauen sollte - durch die Mischung wird's vielleicht noch einen Tick böser, das würde ich aber nicht unbedingt unterschreiben.

Verwende $_REQUEST einfach nicht, und gut ist.

Und zweitens verwendet er anstatt dem Echo-Befehl "print", was imho dasselbe bewirkt.
Steckt da etwa eine Funktionalität dahinter, den ich (noch) nicht realisiert habe?

Akademische Diskussionen beschäftigen sich schon seit Ewigkeiten damit. Es ist in der Praxis total egal. Google, wenn du mehr wissen willst.

- Sven Rautenberg

[KD-one]

Hi Sven,

Danke für deine Antworten, sie haben mir sehr weitergeholfen.
Aber nun treten beim Affenformular größere Schwierigkeiten auf, und zwar im Zusammenhang damit, daß meine Seite dynamisch zusammengebaut wird.
Solo, als Testseite funktioniert das Script http://faq.united-web.at/guestbook/gaestebuch.phps so klaglos, daß ich mich fast selbst schon wundere, wie rasch ich das hinbekommen habe.
Auf meiner reellen Seite allerdings erhalte ich folgende Fehlermeldung:
"Warning: Cannot modify header information - headers already sent by (output started at /home/dunzinger/www/united-web/faq/index.php:3) in /home/dunzinger/www/united-web/faq/guestbook/gaestebuch.php on line 100"
Mir ist schon klar, woher diese Fehlermeldung stammt, nämlich daher, daß die Seite dynamisch zusammengebaut wird und deshalb schon vor dem Script Daten an den Browser gesendet wurden.
Nur, wie kann ich diese Situation umgehen?
Der Code der index.php, in die das Gästebuchscript geschrieben wird:
http://faq.united-web.at/index.phps
Gut, auf den Part mit microtime() könnte ich verzichten, der gibt sowieso nur für mich fallweise interessante Daten am Ende der Seite aus, die zudem im Normalfall nur im Quelltext angezeigt werden, allerdings verursacht include ebenfalls einen Header, und darauf kann ich schon nicht mehr so leicht verzichten.
Würde es etwas bringen, wenn ich auf include verzichte und die Scripte fix in die index.php einbinde?
Wäre halt nur schade, weil es so für mich wesentlich übersichtlicher zu administrieren ist.

Gruß

Kurt

[KD-one]

Hi Sven,

Hab ich doch glatt den Link zur funktionierenden testseite vergessen:
http://faq.united-web.at/guestbook/test/gaestebuch.php

Gruß

Kurt

[Badboy46]

Hab ich doch glatt den Link zur funktionierenden testseite vergessen:
http://faq.united-web.at/guestbook/test/gaestebuch.php

soll das so sien, dass die Gästebucheintrage von links alle ein anderen Abstand haben?!

man kann in dein Gästebuch auch ohne Namen einen Eintrag machen

[KD-one]

Hi Badboy46,

Hab ich doch glatt den Link zur funktionierenden testseite vergessen:
http://faq.united-web.at/guestbook/test/gaestebuch.php

soll das so sien, dass die Gästebucheintrage von links alle ein anderen Abstand haben?!

Nein, natürlich nicht. Da es sich nur um eine Testseite handelt, habe ich dazu kein CSS geschrieben. Noch nicht mal ein Head/Body ist vorhanden. ;-)

man kann in dein Gästebuch auch ohne Namen einen Eintrag machen

Verrate mir bitte mal, wie du das gemacht hast. Das Feld wird mit trim, strip_tags und preg_match bearbeitet, also ist eine Eingabe nur mit Leerzeichen nicht möglich. strlen begrenzt die Mindestangabe an Zeichen auf 2, folglich versteh ich nicht, wie dir das gelungen ist.
Ich hab das in allen möglichen und unmöglichen Varianten durchgetestet und nie Erfolg gehabt, es kam immer eine Fehlermeldung vom Script, abhängig davon, was ich gemacht habe.
Wenn du alles falsch machst(Stringlänge und Leerzeichen in 'name' sowie auch in 'nachricht' und fehlerhafte e-Mail), müssen 5 Fehlermeldungen kommen.
Bei mir zumindest kommen diese.

Das war die Ausgabe, als ich oben beschriebenen Test durchgeführt habe:

---------------------------------------------------------------------------------
Der Name muss mindestens 2 Zeichen lang sein.
Der Name darf nicht nur aus Leerzeichen oder Tabulatoren bestehen.
Geben sie bitte eine gültige oder keine E-Mailadresse ein!
Die Nachricht muss mindestens 5 Zeichen lang sein.
Die Nachricht darf nicht nur aus Leerzeichen oder Tabulatoren bestehen.
---------------------------------------------------------------------------------

Ein Eintrag erfolgte dadurch nicht, er erfolgt aber auch nicht, wenn nur eine mögliche Fehlermeldung kommt.
!?!
Verrat' mir dein Geheimnis.

Gruß

Kurt

[KD-one]

Hi Badboy46,

Verrat' mir dein Geheimnis.

*Lol*, ein Blick in den Quelltext lüftet das Geheimnis. Ich werde wohl etwas umstrukturieren müssen.

Gruß

Kurt

[Badboy46]

Verrat' mir dein Geheimnis.

*Lol*, ein Blick in den Quelltext lüftet das Geheimnis. Ich werde wohl etwas umstrukturieren müssen.

hast also das <b> gesehen *g*

[Sven Rautenberg]

Moin!

*Lol*, ein Blick in den Quelltext lüftet das Geheimnis. Ich werde wohl etwas umstrukturieren müssen.

hast also das <b> gesehen *g*

Grundsatz: Ausnahmslos ALLE Benutzereingaben müssen entweder durch einen regulären Ausdruck, den man auch nicht überlisten kann, auf böse HTML-Zeichen geprüft werden, damit sie entfernt werden, oder die Benutzereingaben werden durch htmlspecialchars() gejagt - danach sind dann alle potentiellen bösen Zeichen auch entschärft.

- Sven Rautenberg

[Badboy46]

Hallo Sven,

hat es ein grund, warum du immer "htmlspecialchars()" empfielst?
ich verwende normalerweise immer "htmlentities($variable,ENT_QUOTES)"

ist "htmlentities" schlechter?

[Sven Rautenberg]

Moin!

hat es ein grund, warum du immer "htmlspecialchars()" empfielst?

Diese Funktion codiert die absolut notwendigen Zeichen in Entities um.

ich verwende normalerweise immer "htmlentities($variable,ENT_QUOTES)"

Diese Funktion codiert zusätzlich noch alle möglichen Sonderzeichen in Entities um.

ist "htmlentities" schlechter?

Es tut mehr - deshalb braucht es wahrscheinlich unwesentlich länger. Aber da ich in der Regel auf den verwendeten Zeichensatz achte, muß ich Umlaute etc. nicht in Entities wandeln.

- Sven Rautenberg

[Sven Rautenberg]

Moin!

Auf meiner reellen Seite allerdings erhalte ich folgende Fehlermeldung:
"Warning: Cannot modify header information - headers already sent by (output started at /home/dunzinger/www/united-web/faq/index.php:3) in /home/dunzinger/www/united-web/faq/guestbook/gaestebuch.php on line 100"
Mir ist schon klar, woher diese Fehlermeldung stammt, nämlich daher, daß die Seite dynamisch zusammengebaut wird und deshalb schon vor dem Script Daten an den Browser gesendet wurden.

Dann beseitige dies. Es gibt keine andere Möglichkeit. Tausende gleichlautende Hinweise findest du in unserem Archiv.

Nur, wie kann ich diese Situation umgehen?

Verbessere deine Seitenskripte enorm.

Das Problem deiner jetzigen Herangehensweise ist, dass du das Prinzip EVA nicht einhälst auf deiner Index-Seite: Eingabe - Verarbeitung - Ausgabe.

Sondern du fängst gleich mit der Ausgabe des DOCTYPE an, und dann erst kommt ein wenig PHP zum Zuge, verteilt auf die ganze Seite. Sowas ist schlecht.

Gut hingegen wäre, wenn du dir eine beliebige Template-Engine zulegen würdest (die hat den Vorteil, dass man sich seine Seiten designmäßig einheitlich zusammensetzen kann), und dich dann streng an das EVA-Prinzip hälst:

1. Entgegennahme, Vollständigkeits- und Plausibilitätsprüfung der vom User eingegebenen Daten. Dieser Punkt entfällt bei dem ersten Aufruf der Startseite beispielsweise vollkommen, weil der Benutzer da noch nichts sendet. Aber er könnte ja. Genauso beim Gästebuch.

2. Verarbeitung und Aufbereitung der Daten. Dazu zählt auch, die Template-Engine mit den notwendigen Informationen zu füttern, also Inhalte und Templates von Platte lesen, ggf. Benutzerinformationen einfügen etc. Vielleicht muß an dieser Stelle auch entschieden werden, welches von mehreren Templates gewählt wird, oder welche Informationen ausgegeben werden müssen.

3. Ausgabe der fertigen Seite. Das kann entweder (wenn man auf Template-Engines verzichten möchte) als lange, untem am PHP-Skript dranhängende Seite geschehen, in der an den verschiedenen Stellen Variablen ausgegeben oder HTML-Fragmente eingebunden werden, oder eben durch Aufruf der Parse-Methode der Template-Engine. Je nach Anwendungsfall könnten hier zu Beginn auch zwischen den verschiedenen möglichen Seitenversionen unterschieden werden, so dass mehrere komplette HTML-Seiten mit IF/ELSE oder SWITCH am Skript dranhängen.

- Sven Rautenberg

[KD-one]

Hi Sven,

Boah ey, das wird eine Riesenbaustelle.
Ich hab mich mal vorläufig dazu entschieden, das Gästebuch aus dem Seitenscript auszuklammern und direkt zu verlinken, dann hab ich auch keinen Druck und die nötige Ruhe, die Site umzugestalten.
Danke für deine Antwort.

Gruß

Kurt

[KD-one]

Hi alle,

So, ich denke, ich habe alle Kritikpunkte beseitigt bis auf die E-Mailprüfung.
Die kommt morgen abend dran.

http://faq.united-web.at/guestbook/gaestebuch.phps
http://faq.united-web.at/guestbook/write.phps

Danke euch für eure Kritik.

Gruß

Kurt