php Antwort vom Formular funktioniert nicht auf index.php
henman
TS
Matthias Apsel
AugeHallo,
ich habe ein Formuar auf meiner index.php Seite. Mein php-Quellcode setzt bei Klick auf "Senden" einen Dankestext auf die Webseite und sendet eine Email an meine EMailadresse. Auf meiner index.php funktioniert das nicht. Um den Fehler einzugrenzen habe ich eine Testseite erstellt. http://www.mehlhop.com/test.php Ich habe sie nach und nach der index.php angepasst und dort funktioniert der Antworttext einwandfrei. (Bitte scheut Euch nicht das Formular zu testen!) Es gibt nur zwei kleine Unterschiede auf den beiden Seiten:
<?php
if ($_POST["send"]) {
echo ' <p>Vielen Dank für Ihre Nachricht!<br /><br />Mit freundlichen Grüßen!<br />Frank Mehlhop<br /><a href="index.php#kontakt" target="_parent"><span class="glyphicon glyphicon-backward"></span> Zurück zum Formular.</a></p>';
$inhalt_email="Nachricht vom Kontaktformular auf www.mehlhop.com:\n\nvon\n".$_POST[name]."\nE-Mail: ".$_POST[email]."\nNachricht:\n".$_POST[comments]."\n\nEnde der Nachricht.";
$betreff="Kontaktformular-mehlhop.com, Nachricht von ".$_POST[name];
mail("info@mehlhop.com", $betreff, $inhalt_email, "From: ".$_POST[email]);
} else {
?>
<form id="message" action="index.php#kontakt" method="post">...
1.) in Zeile 3 bzw. 4 steht der Link <a href="index.php#kontakt" statt test.php, was aber nicht relevant sein dürfte, weil dies nicht aufgerufen wird. 2.) im Tag <form steht action="index.php#kontakt" statt action="test.php#kontakt", was mir korrekt erscheint.
Warum funktioniert der Antworttext und das Senden der Email auf der text.php, aber nicht auf der index.php? Hat jemand eine Idee dazu?
Würde mich freuen dieses Problem lösen zu können.
Grüße und Dank sagt Frank
--
www.mehlhop.com
www.mehlhop.com
akzeptierte Antworten
php Antwort vom Formular funktioniert nicht auf index.php
dedlfix
Bewertung: keine Bewertung
-
Servus FrankMe,
if ($_POST["send"]) { echo ' <p>Vielen Dank für Ihre Nachricht!<br /><br />Mit freundlichen Grüßen!<br />Frank Mehlhop<br /><a href="index.php#kontakt" target="_parent"><span class="glyphicon glyphicon-backward"></span> Zurück zum Formular.</a></p>'; $inhalt_email="Nachricht vom Kontaktformular auf www.mehlhop.com:\n\nvon\n".$_POST[name]."\nE-Mail: ".$_POST[email]."\nNachricht:\n".$_POST[comments]."\n\nEnde der Nachricht."; $betreff="Kontaktformular-mehlhop.com, Nachricht von ".$_POST[name]; mail("info@mehlhop.com", $betreff, $inhalt_email, "From: ".$_POST[email]); } else { // ...1.) in Zeile 3 bzw. 4 steht der Link <a href="index.php#kontakt" statt test.php, was aber nicht relevant sein dürfte, weil dies nicht aufgerufen wird. 2.) im Tag <form steht action="index.php#kontakt" statt action="test.php#kontakt", was mir korrekt erscheint.
Warum funktioniert der Antworttext und das Senden der Email auf der text.php, aber nicht auf der index.php?
Als erstes würde ich wohl testen, ob es
$_POST["send"]wirklich gibt, wenn das Formular abgesendet wurde.ciao
--
"Sir, we are surrounded" - "Excellent, we can attack in any direction!"-
Als erstes würde ich wohl testen, ob es
$_POST["send"]wirklich gibt, wenn das Formular abgesendet wurde.Ich würd' mir grad' mal das gesamte $_POST-Array ausgeben.
Tzz
-
Als erstes würde ich wohl testen, ob es
$_POST["send"]wirklich gibt, wenn das Formular abgesendet wurde.Hallo und danke für Eure Antworten.
auf index.php bleibt $_POST["send"] leer, auf test.php steht nach dem Klick "S e n d e n" in der Variable.
Daher wird natürlich auch nie die Anweisung
if ($_POST["send"]) {...}angesprochen.
-
-
Hallo und guten Abend,
was steht denn genau im <Form> ?
Deine Ausgabe enthält Sicherheitslücken. Du hast keine Zielkontextanpassung der Ausgaben vorgenommen und die Eingaben auch nicht gefiltert.
Grüße
TS-
Hi TS,
danke für deine Info,
bevor ich mich mit den Sicherheitslücken beschäftige erst mal das komplette <form>-Tag. Die darin befindlichen div's beziehen sich auf das Bootstrap-Layour.
<form id="message" action="index.php#kontakt" method="post"> <div class="row"> <div class="col-sm-6 form-group"> <input class="form-control" id="name" name="name" placeholder="Name" type="text" required> </div> <div class="col-sm-6 form-group"> <input class="form-control" id="email" name="email" placeholder="Email" type="email" required> </div> </div> <textarea class="form-control" id="comments" name="comments" placeholder="Nachricht" rows="5" ></textarea><br> <div class="row"> <div class="col-sm-12 form-group"> <input class="btn btn-default pull-right" type="submit" id="send" name="send" value="S e n d e n" /> </div> </div> </form>-
Hallo FrankMe,
bevor ich mich mit den Sicherheitslücken beschäftige erst mal das komplette <form>-Tag.
Element ;-)
Bis demnächst
Matthias -
Hallo FrankMe,
<form id="message" action="index.php#kontakt" method="post"> <div class="row"> <div class="col-sm-6 form-group"> <input class="form-control" id="name" name="name" placeholder="Name" type="text" required> </div> <div class="col-sm-6 form-group"> <input class="form-control" id="email" name="email" placeholder="Email" type="email" required> </div> </div> <textarea class="form-control" id="comments" name="comments" placeholder="Nachricht" rows="5" ></textarea><br> <div class="row"> <div class="col-sm-12 form-group"> <input class="btn btn-default pull-right" type="submit" id="send" name="send" value="S e n d e n" /> </div> </div> </form>Ein paar Kritikpunkte:
- Es fehlen die label-Elemente
type="text"ist der default-Wert, kann also weggelassen werdenplaceholdersoll eine Beispielangabe enthalten, keine Beschritung, siehe Wiki- Zeilenumbrüche sind keine Abstände
- Für buttons gibt es das Button-Element siehe Blog
- Leerzeichen sind keine Abstände
Bis demnächst
Matthias
-
-
Hallo TS,
was meinst du mit Zielkontextanpassung und Eingabe filtern? Ich werde nicht draus schlau.
Frank
-
Hallo FrankMe,
was meinst du mit Zielkontextanpassung und Eingabe filtern? Ich werde nicht draus schlau.
Du fügst
$_POST[name]in deine Ausgabe ein. Böse Buben könnten dort JavaScript zur Ausführung bringen oder einen Link zu einer „netten“ Seite setzen. Siehe Wiki.Bis demnächst
Matthias -
Tach!
was meinst du mit Zielkontextanpassung und Eingabe filtern?
Der Kontext ist hier die mail()-Funktion. Solange du da keine HTML-Mail schickst, ist das Format dieser Mail Plaintext. Da gibt es nichts, was angepasst werden muss. Allerdings nimmt die Funktion neben dem Mailtext auch noch andere Parameter entgegen.
Der Empfänger: ist bei dir ein fest kodierter Wert, alles bestens. Ansonsten gilt dasselbe wie beim Betreff.
In den Betreff schreibst du eine Nutzereingabe und die landet in den Headerzeilen. Das ist aber kein Problem, weil da alle nichtdruckbaren Zeichen von PHP gefiltert werden.
Der Inhalt der Mail unterliegt keinen Beschränkungen.
Die zusätzlichen Headerzeilen allerdings sind kritisch. Du musst da selbst die Zeilen bilden. Und nun kommt jemand daher und gibt als seine Mailadresse "foo@example.com\r\nCc: Liste_mit_Adressen" an. Und damit hast du eine Spamschleuder gebaut.
Du musst prüfen, ob in dem Wert
\roder\nenthalten sind. Wenn ja, kannst und solltest du die weitere Verarbeitung des Scripts abbrechen. Du brauchst auch keine Fehlermeldung zu antworten, die liest eh kein Bot.Im Kontextwechsel-Artikel gibt es auch einen Abschnitt zur E-Mail für ausführliche Information.
dedlfix.
-
Herzlichen Dank für den Sicherheitshinweis! Ich bin froh, dass Ihr mich darauf hingewiesen habt. Nun habe ich das php angepasst und das sieht jetzt so aus:
<?php echo 'Ausgabe Test: '.$_POST["send"]."<br />"; if ($_POST["send"]) { echo '<p>Vielen Dank für Ihre Nachricht!<br /><br />Mit freundlichen Grüßen!<br />Frank Mehlhop<br /><a href="index.php#kontakt" target="_parent"><span class="glyphicon glyphicon-backward"></span> Website und Formular zurücksetzen.</a></p>'; $from = $_POST[email]; function is_printable($value, $utf8 = false) { $pattern = '~^\P{C}+\z~' . ($utf8 ? 'u' : ''); return (bool)preg_match($pattern, $value); } if (!is_printable($from) or !is_printable($cc)) // $from oder $cc enthält nicht nur druckbare Zeichen die(); // Abbruch wegen potentiellen Missbrauchs $inhalt_email="Nachricht vom Kontaktformular auf www.mehlhop.com:\n\nvon\n".$_POST[name]."\nE-Mail: ".$_POST[email]."\nNachricht:\n".$_POST[comments]."\n\nEnde der Nachricht."; $betreff="Kontaktformular-mehlhop.com, Nachricht von ".$_POST[name]; mail("info@mehlhop.com", $betreff, $inhalt_email, "From: ".$from."\n"); } else { ?>Hat jemand evtl. noch eine Idee zu dem Problem, welches ich hier gepostet habe.
-
Tach!
if (!is_printable($from) or !is_printable($cc))Wo kommt denn jetzt das $cc her? Bitte vor dem Kopieren von Code diesen verstehen und an den eigenen Anwendungsfall anpassen.
Hat jemand evtl. noch eine Idee zu dem Problem, welches ich hier gepostet habe.
Ich hab nicht ganz verstanden, was bei da bei dir läuft oder nicht läuft. Du solltest das mal mit den vorhandenen Hilfsmittel genauer untersuchen. Die Entwicklertools im Browser wären ein solches. Wird der Request abgesendet, und wenn ja, auch in der Form, die du dir vorgestellt hast?
dedlfix.
-
Danke dedlfix,
die Funktion habe ich angepasst. War unsauber gearbeitet, geb ich zu.
Mit den Entwicklertools habe ich aber leider keinen Erkenntnisgewinn. Man sieht das Problem auch wirklich erst, wenn man es versucht, das Formular ausgefüllt zu senden (das hat scheinbar noch niemand beim test.php-Formular versucht). Wie ich es zu Beginn des Threads beschrieben habe. (Oder ist es nicht verständlich?)
In einer "Software", also wenn ich mit Java oder C# arbeite, dann setze ich einfach einen Breakpoint. Aber im Browser mit Entwicklertools weiß ich nicht, wie das gehen soll. Ich sehen nicht mal die Variablen. Ich weiß auch nicht, wie ich das Event "submit" sichtbar machen kann. Natürlich habe ich dort herumgespielt und probiert, aber ohne Erkenntnisgewinn.
Ich lasse den Variablenwert von $_POST["send"] oberhalb vom Formular anzeigen. Zu Anfang (Webseite wird geladen) ist dieser leer. Wenn ich auf der Seite index.php auf "Senden" klicke, bleibt die Variable leer. Wenn ich auf der (fast identischen Seite) test.php auf "Senden" klicke, wird der Wert "S e n d e n" angezeigt, der Dankestext erscheint und die Email wird gesendet. Der einzige Unterschied zwischen beiden Seiten ist, dass innerhalb des php-Blocks (siehe Eingangseintrag) statt index.php test.php steht.
Frank
-
Danke dedlfix,
die Funktion habe ich angepasst. War unsauber gearbeitet, geb ich zu.
Mit den Entwicklertools habe ich aber leider keinen Erkenntnisgewinn.
Wenn Du effizient entwickeln willst, setze Deine Webanwendung in einen try-Block und gib die Exception mit
Content-Type: text/plainaus.So kannst Du, insbesondere beim Kennenlernen/Entwickeln neuer Module, auch mal selbst eine Exception als Dump in den Browser werfen und gucken wie die Daten aussehen.
-
Tach!
Wenn Du effizient entwickeln willst, setze Deine Webanwendung in einen try-Block und gib die Exception mit
Content-Type: text/plainaus.Das ist nicht zielführend. PHP erzeugt keine Exceptions abseits von einigen ausgewählten Bereichen.
So kannst Du, insbesondere beim Kennenlernen/Entwickeln neuer Module, auch mal selbst eine Exception als Dump in den Browser werfen und gucken wie die Daten aussehen.
Ein var_dump() tut es ganz ohne den nahezu unnützen try-catch-Block. Dazu ein <pre> vorher ausgegeben oder in die Quellcode-Ansicht des Browsers geschaut, ist ebenfalls einfacher als einen HTTP-Header auszugeben, der noch dazu den ganzen Rest der Ausgabe gleich mit vertextet.
dedlfix.
-
Tach!
Wenn Du effizient entwickeln willst, setze Deine Webanwendung in einen try-Block und gib die Exception mit
Content-Type: text/plainaus.Das ist nicht zielführend. PHP erzeugt keine Exceptions abseits von einigen ausgewählten Bereichen.
Ich beschreibe eine zielführende Vorgehensweise zum Entwickeln von Webanwendungen -- unabhängig von der Programmiersprache.
So kannst Du, insbesondere beim Kennenlernen/Entwickeln neuer Module, auch mal selbst eine Exception als Dump in den Browser werfen und gucken wie die Daten aussehen.
Ein var_dump() tut es ganz ohne den nahezu unnützen try-catch-Block. Dazu ein <pre> vorher ausgegeben oder in die Quellcode-Ansicht des Browsers geschaut, ist ebenfalls einfacher als einen HTTP-Header auszugeben, der noch dazu den ganzen Rest der Ausgabe gleich mit vertextet.
Die Nützlichkeit try/catch besteht, wie ich beschreibe darin, einen
- geeigneten Content-Type-Header zu erzeugen, damit etwaige Dumps gut lesbar dargestellt werden können, text/html macht <pre> überflüssig,
- geeigneten Status-Code auszugeben, damit nachgelagerte Prozesse automatisierbar sind.
(2) ist insbesondere für Ajax interessant, Beispiel:
if( this.status != 200) return alert(this.response);Was es serverseitig unnötig macht, etwaige Fehlermeldungen bspw. in JSON's zu verpacken: Wenn eine Exception fällt wird zusammen mit einem dazu passenden HTTP-Status der Fehlertext ausgegeben. Das ist Best Practice. Und selbstverständlich ist das alles auch mit PHP machbar: Eine konsequente Nutzung des jeweiligen Exception-Modells.
Kannst mir glauben, wenn ich hier was poste, steckt da stets eine gehörige Portion Erfahrung dahinter. Die unter Anderem auch darin besteht, gelernt zu haben wie man's besser nicht machen sollte.
Ein var_dump() tut es ganz ohne den nahezu unnützen try-catch-Block.
So ein Stuss. Hast Du überhaupt verstanden was ich hier beschreibe!? Einen zweckmäßigen Umgang mit Exceptions -- Was letztendlich auch einen erheblichen Zeitgewinn erbringt. Für einen der selbstständig ist pures Geld!
MfG
-
Tach!
Ich beschreibe eine zielführende Vorgehensweise zum Entwickeln von Webanwendungen -- unabhängig von der Programmiersprache.
Wie kann das zielführend sein, wenn die Programmiersprache das gar nicht unterstützt? Zumindest nicht auf die Weise, wie du das vorschlägst.
Die Nützlichkeit try/catch besteht, wie ich beschreibe darin, einen
- geeigneten Content-Type-Header zu erzeugen, damit etwaige Dumps gut lesbar dargestellt werden können, text/html macht <pre> überflüssig,
Natürlich. Schon eine ganze Zeile mit einem kompletten Funktionsaufruf kann ein simples Fünf-Zeichen-<pre> einsparen.
- geeigneten Status-Code auszugeben, damit nachgelagerte Prozesse automatisierbar sind.
Ein nachgelagerter Prozess beim Entwickeln?
Ein var_dump() tut es ganz ohne den nahezu unnützen try-catch-Block.
So ein Stuss. Hast Du überhaupt verstanden was ich hier beschreibe!?
Mit diesem Stuss arbeiten PHP-Programmierer in der Regel effektiv und effizient, um Fehler während des Entwicklungsprozesses zu finden. Kann sein, dass du es nur halb erklärt hast. Mir geht es gerade nur darum, einen aktuellen Fehler zu finden, der anschließend beseitigt wird. Dir geht es wohl auch um die Laufzeit und nicht nur um die Entwicklung, wie dein einleitender Halbsatz jedoch vermuten ließ.
Einen zweckmäßigen Umgang mit Exceptions -- Was letztendlich auch einen erheblichen Zeitgewinn erbringt. Für einen der selbstständig ist pures Geld!
Ja, wenn denn PHP ausschließlich Exceptions erzeugen würde. Aber, wie gesagt, Exceptions sind die Ausnahme, eine seltene noch dazu. Etwas, das für den vorliegenden Fall nicht zielführend ist, kann nichts sparen.
Wenn es darum geht, PHP-Fehlermeldungen für den laufenden Betrieb zu bekommen, gibt es auch noch das Error-Log und die Funktion error_log(), um selbst was da abzulegen. Das ist bereits in PHP eingebaut, muss man gegebenenfalls nur konfigurieren und nichts weiter dazu programmieren.
Wenn es denn was pomforzionöses sein soll, dann braucht man in PHP einen Error-Handler.
dedlfix.
-
-
-
Tach!
Mit den Entwicklertools habe ich aber leider keinen Erkenntnisgewinn. Man sieht das Problem auch wirklich erst, wenn man es versucht, das Formular ausgefüllt zu senden (das hat scheinbar noch niemand beim test.php-Formular versucht). Wie ich es zu Beginn des Threads beschrieben habe. (Oder ist es nicht verständlich?)
Es ist mir nicht klar geworden, was nun in welcher Datei steht und somit, wer was aufrufen soll.
In einer "Software", also wenn ich mit Java oder C# arbeite, dann setze ich einfach einen Breakpoint. Aber im Browser mit Entwicklertools weiß ich nicht, wie das gehen soll. Ich sehen nicht mal die Variablen. Ich weiß auch nicht, wie ich das Event "submit" sichtbar machen kann. Natürlich habe ich dort herumgespielt und probiert, aber ohne Erkenntnisgewinn.
Du kannst im Browser nur sehen, was im Browser abläuft. Der hat natürlich keine Ahnung von den Vorgängen auf dem Server. Aber das, was im Browser abläuft, ist ja schon die Hälfte des Gesamtvorganges. Du kannst dort sehen, ob der Request abgesendet wird, welchen Inhalt der hat und wie er beantwortet wird. Wenn man den Ablauf so nachvollziehen möchte, wie er vonstattengeht, ist das der erste Prüfschritt. Die Erkenntnis daraus ist, ob der Request wie vorgesehen erzeugt wurde.
Ich lasse den Variablenwert von $_POST["send"] oberhalb vom Formular anzeigen.
var_dump() ist zum Testen besser geeignet als echo. echo konvertiert einige Werte zu Zahlen oder Leerzeichen oder Ersatzstrings, var_dump() bietet exaktere Informationen.
Zu Anfang (Webseite wird geladen) ist dieser leer. Wenn ich auf der Seite index.php auf "Senden" klicke, bleibt die Variable leer.
"Leer" ist kein Zustand. Ist es Leerstring oder null? var_dump() kann es unterscheiden. Dazu (zum Entwickeln immer) error_reporting auf E_ALL und display_errors auf 1 gestellt, bringt bessere Erkenntnisse, durch die Anzeige sonst unterdrückter Meldungen.
dedlfix.
-
Hallo,
ich habe echo durch var_dump ersetzt (danke für den Hinweis!). Statt nichts wird nun NULL ausgegeben. Das ist sicher ein wichtiger Hinweis der mir demnächst beim Debuggen helfen wird. Aber ich denke es ist klar, dass $_POST["send"] Null ist, sonst würde mir der Ablauf in die if-Abfrage reinlaufen. M.E. müsste ich herausfinden, warum bei index.php beim Klick auf Senden der Wert der Variable $_POST["send"] nicht gesetzt wird (im Unterschied zur identischen test.php). Die Seite wird nach dem Klick neu geladen und zu dem Anker gescrollt.
<form id="message" action="test.php#kontakt"...Übrigens habe ich auch das Element Button getestet und das Verhalten war das Selbe.
-
Tach!
ich habe echo durch var_dump ersetzt (danke für den Hinweis!). Statt nichts wird nun NULL ausgegeben. Das ist sicher ein wichtiger Hinweis der mir demnächst beim Debuggen helfen wird.
Ja, der bedeutet, dass der Eintrag im $_POST-Array vermutlich nicht existiert. Dazu hättest du eine Notice-Meldung sehen können, wenn du das error_reporting nebst display_errors entsprechend konfiguriert hättest.
Aber ich denke es ist klar, dass $_POST["send"] Null ist, sonst würde mir der Ablauf in die if-Abfrage reinlaufen.
Noch nicht, es könnte ja auch ein Leerstring sein. In dem Fall existiert der Eintrag im $_POST-Array, und der Fall sähe etwas anders aus.
M.E. müsste ich herausfinden, warum bei index.php beim Klick auf Senden der Wert der Variable $_POST["send"] nicht gesetzt wird (im Unterschied zur identischen test.php). Die Seite wird nach dem Klick neu geladen und zu dem Anker gescrollt.
Es kann nur gesetzt werden, wenn es der Browser mitschickt. Deswegen möchte ich ja, dass du da mal untersuchst, was der Browser für einen Request erzeugt. Das soll prüfen, ob die Voraussetzungen überhaupt gegeben sind. Diese Abläufe basieren ja nicht auf Magie, sondern auf nachprüfbaren Gegebenheiten.
dedlfix.
-
Danke dedlfix, für deine Geduld und Unterstützung!
Es kann nur gesetzt werden, wenn es der Browser mitschickt. Deswegen möchte ich ja, dass du da mal untersuchst, was der Browser für einen Request erzeugt. Das soll prüfen, ob die Voraussetzungen überhaupt gegeben sind. Diese Abläufe basieren ja nicht auf Magie, sondern auf nachprüfbaren Gegebenheiten.
Ich arbeite mit Chrome. In den Entwicklertools finde ich unter Network nach dem Klick auf Senden und dem Öffnen der index.php / Header die auffällige Meldung: Status Code: (gelber Punkt) 301 Moved Permanently. Weiterhin fällt auf, dass unter Response Headers X-Pad:avoid browser bug steht (wobei ich nicht weiß, was das bedeuten soll).
Für mich klingt das nach fehlerhaften Einstellungen beim Provider. Was meint Ihr?
-
Hallo und guten Morgen,
Ich arbeite mit Chrome.
Zum Testen könntest Du temporär aber einen anderen Browser einsetzen? Oder ist der Crome bei Dir fest ins ROM gemeißelt und als einziger Gott zulässig?
Grüße
TS-
Ja natürlich könnte ich auch einen anderen Browser benutzen. Aber was soll da bringen?
-
Ja natürlich könnte ich auch einen anderen Browser benutzen. Aber was soll da bringen?
Das würde sich vorteilhaft auf Deine Tätigkeit als selbstständiger Programmierer auswirken.
MfG
-
Das würde sich vorteilhaft auf Deine Tätigkeit als selbstständiger Programmierer auswirken.
Weil Programmierer die den IE oder Firefox nutzen beliebter sind?! ;) In den Developertools von Firefox komme ich zum selben Ergebnis wie in Chrome. Wenn ich erklären möchte was ich wo in den Entwicklertools sehe, dann sollte ich evtl. auch erwähnen in welchen Browser?! Manchmal fällt es schwer solche Aussagen wie deine pl nicht zu persönlich zu nehmen.
-
Das würde sich vorteilhaft auf Deine Tätigkeit als selbstständiger Programmierer auswirken.
Weil Programmierer die den IE oder Firefox nutzen beliebter sind?! ;)
Was ein Programmierer an Browser benutzt ist dem Kunden völlig egal.
Manchmal fällt es schwer solche Aussagen wie deine pl nicht zu persönlich zu nehmen.
Ein Kunde erwartet fachliche Kompetenz. Ein Entwickler sollte sich seine Ergebnisse mit verschiedenen Browsern angucken bevor es der Kunde tut.
MfG
-
-
-
Hallo FrankMe,
Ja natürlich könnte ich auch einen anderen Browser benutzen. Aber was soll da bringen?
Unabhängig von deinem konkreten Problem solltest du deine Seiten in vielen verschiedenen Browsern und Konfigurationen testen. Im konkreten Fall hilft ein anderer Browser natürlich nicht.
Bis demnächst
Matthias
-
-
-
Tach!
Ich arbeite mit Chrome. In den Entwicklertools finde ich unter Network
Da ist auch eine Checkbox zu finden, in der man die Nutzung des Caches unterbinden kann. Der verhindert auch gern mal Requests.
nach dem Klick auf Senden und dem Öffnen der index.php / Header die auffällige Meldung: Status Code: (gelber Punkt) 301 Moved Permanently.
Da schau mal genauer nach, besonders die Location-Zeile in der Response. Was ist requested, wo leitet es hin? Und stimmt die Request-Methode (POST/GET)?
Weiterhin fällt auf, dass unter Response Headers X-Pad:avoid browser bug steht (wobei ich nicht weiß, was das bedeuten soll).
Header, die mit X- anfangen, sind nicht standardisiert. Das können einfach nur Informationen sein, oder irgendwelche Clients werten das aus. Man kann die üblicherweise ignorieren, wenn man sie nicht selbst gesetzt hat.
dedlfix.
-
nach dem Klick auf Senden und dem Öffnen der index.php / Header die auffällige Meldung: Status Code: (gelber Punkt) 301 Moved Permanently.
Da schau mal genauer nach, besonders die Location-Zeile in der Response. Was ist requested, wo leitet es hin? Und stimmt die Request-Methode (POST/GET)?
Die Location ist http://www.mehlhop.com/. Sieht also perfekt aus. Ich verwende Post als Request-Methode. Ich denke dies ist ok so. Wie gesagt funktioniert auf der identischen test.php und die Variablen und Werte werden auch (entsprechend Entwicklertools) richtig übergeben.
-
Tach!
Die Location ist http://www.mehlhop.com/. Sieht also perfekt aus.
Nein, sieht es nicht. Wenn du index.php als Ziel angibst, darf der Request nicht nach / gehen. Der Browser muss ihn zu einem absoluten Pfad ausgehend vom DocumentRoot umschreiben, darf dabei aber nichts weglassen. In deinem Fall muss er /index.php als Request absenden (dazu Host: www.mehlhop.com). Da liegt wohl also der Hase im Pfeffer.
Ich verwende Post als Request-Methode. Ich denke dies ist ok so.
Ja, das ist ok. Aber beim Fehlersuchen kommt es nicht darauf an, was du möchtest, sondern das was wirklich passiert. Also bitte kontrollieren, ob es auch so stattfindet.
Wie gesagt funktioniert auf der identischen test.php und die Variablen und Werte werden auch (entsprechend Entwicklertools) richtig übergeben.
Dann schau mal dabei in die Entwicklertools, was da im Request anders ist.
dedlfix.
-
Nein, sieht es nicht. Wenn du index.php als Ziel angibst, darf der Request nicht nach / gehen. Der Browser muss ihn zu einem absoluten Pfad ausgehend vom DocumentRoot umschreiben, darf dabei aber nichts weglassen. In deinem Fall muss er /index.php als Request absenden (dazu Host: www.mehlhop.com). Da liegt wohl also der Hase im Pfeffer.
Das glaube ich auch.
Ich verwende Post als Request-Methode. Ich denke dies ist ok so.
Ja, das ist ok. Aber beim Fehlersuchen kommt es nicht darauf an, was du möchtest, sondern das was wirklich passiert. Also bitte kontrollieren, ob es auch so stattfindet.
Ich denke schon, dass das ok ist, da ja die Werte in den Entwicklertools korekt angezeigt werden. Oder?
Wie gesagt funktioniert auf der identischen test.php und die Variablen und Werte werden auch (entsprechend Entwicklertools) richtig übergeben.
Dann schau mal dabei in die Entwicklertools, was da im Request anders ist.
Die zwei Unterschiede, die mir ins Auge fielen, habe ich schon genannt. Aber ich zeige mal die jeweiligen Screenshots, bevor ich viele Worte mache... index.php Request nach "Senden"-Button-Klick:
und hier test.php Request nach "Senden"-Button-Klick:
-
Tach!
Die zwei Unterschiede, die mir ins Auge fielen, habe ich schon genannt. Aber ich zeige mal die jeweiligen Screenshots, bevor ich viele Worte mache... index.php Request nach "Senden"-Button-Klick:
und hier test.php Request nach "Senden"-Button-Klick:
Ok, nun wird das Bild klarer. Der Server hat da wohl eine Regel, die das Aufrufen von /index.php umleitet auf
/, und das wird dann intern anscheinend wieder auf /index.php geleitet. Falls du da nicht selbst eine header('Location:...')-Zeile in deinem Code hast. Du müsstest außer dem 301er einen zweiten Request sehen, der auf/geht. Vermutlich ist das dann ein GET-Request ohne weitere Formulardaten.Weiter geht es also, nachdem du herausgefunden hast, wer für die Umleitung zuständig ist.
Alternativ könnte es auch klappen, wenn du nicht auf
index.php#kontaktlinkst, sondern auf/#kontakt. Ich bin mir aber grad nicht sicher, ob der Browser das nicht rauskürzt und gleich zum Anker springt. Dürfte aber bei POST nicht sein.dedlfix.
-
Hallo,
Ok, nun wird das Bild klarer. Der Server hat da wohl eine Regel, die das Aufrufen von /index.php umleitet auf
/, und das wird dann intern anscheinend wieder auf /index.php geleitet. Falls du da nicht selbst eine header('Location:...')-Zeile in deinem Code hast. Du müsstest außer dem 301er einen zweiten Request sehen, der auf/geht. Vermutlich ist das dann ein GET-Request ohne weitere Formulardaten.Du hast recht, es gibt einen weiteren Aufruf mit Get und ohne Variablen / Werte. Intern habe ich keinen weiteren Aufruf erstellt. Und es muss irgendwie an der index.php hängen. Ich vermute es hat irgendwie mit dem Server / Provider zu tun, da der selbe Code auf test.php nicht ein zweites Mal mit Get-Request aufruft. Hierfür füge ich noch zwei ScreenShots unten hinzu. In der linken Spalte sieht man die zwei folgenden Aufrufe (Aufruf 1 und 2) und daneben die Hearer. Seit Ihr / bist Du auch der Meinung, dass es an einer Einstellung beim Provider liegen muss?
Alternativ könnte es auch klappen, wenn du nicht auf
index.php#kontaktlinkst, sondern auf/#kontakt. Ich bin mir aber grad nicht sicher, ob der Browser das nicht rauskürzt und gleich zum Anker springt. Dürfte aber bei POST nicht sein.Hilft nix. Hab ich getestet.
Herzliche Grüße, Frank
Aufruf 1:
Aufruf 2:
-
Tach!
Du hast recht, es gibt einen weiteren Aufruf mit Get und ohne Variablen / Werte.
Gut. Das ist also die Ursache für das beobachtete Verhalten. Der Server nimmt den Request nicht entgegen, sondern schickt einen Redirect und der kommt ohne Daten daher.
Intern habe ich keinen weiteren Aufruf erstellt. Und es muss irgendwie an der index.php hängen.
Generelle Konfiguration des Webservers oder .htaccess kämen als Ursache infrage.
Mal was anderes, muss es denn unbedingt die index.php sein, in der das Formular ausgewertet wird? Du kannst auch eine separate Datei erstellen (z.B. mail.php), die den Mailversand erledigt und anschließend einen Redirect zurück auf /#kontakt als Antwort sendet. Das wäre auch die einzige Lösung, die mir grad einfällt, wenn das Weiterleiten von /index.php auf / nicht wegzukonfigurieren geht.
dedlfix.
-
Yippie!
VIELEN VIELEN DANK DEDLFIX !!!
Generelle Konfiguration des Webservers oder .htaccess kämen als Ursache infrage.
ich habe mal eine .htacces vor einigen Jahren geschrieben und Fehlerseiten anzuzeigen und um auf www weiterzuleiten, wenn dies nicht explizit eingegeben wurde. Nun habe ich folgende Zeile entfernt: RewriteRule ^index.(html?|php)$ http://%{HTTP_HOST}/ [R=301,QSA,L] und es funktioniert.
Danke dedlfix!!! Und danke allen anderen, die mir helfen wollten!!!
Nebenbei habe ich glaube wieder so einiges gelernt.
-
-
-
-
Hallo FrankMe,
[… Screenshots …]
Fürs nächste mal: Du kannst die Screenshots auch hier hochladen (siehe Dropzone unter der Textarea). Das hat den Vorteil, dass man hier keine „mixed media”-Warnung bekommt, weil die Ressourcen nicht via HTTPS erreichbar sind :)
LG,
CK-
Danke sehr Christian für den Hinweis. Das hatte ich nicht gesehen und es macht es natürlich viel einfacher Bilder einzufügen. :-)
Frank
-
-
-
-
Hallo
Da du in mehreren Postings geklagt hast, du fändest in der Konsole nur zwei Zeilen (der 301-er und den X-irgendwas-Header), sei zur Ergänzung des von @dedlfix gerade zum wiederholten Male empfohlenen Blicks in die Entwicklerkonsole deines Browsers hinzugefügt, dass – zumindest im Firefox und ich gehe davon aus, dass das auch im Chrome so ist – die einzlnen Zeilen der Ausgabe der Konsole aufklappbar sind, woraufhin sie weitere Informationen preisgeben.
Hier mal ein Beispiel aus dem Firefox (ausklappen über die Dreiecke am Zeilenbeginn):
Tschö, Auge
--
Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
Wolfgang Schneidewind *prust*-
Hallo Auge!
Warum nennst du dich so? Wenn du sehen würdest, dann hättest du in meinen ScreenShots erblickt, dass alles ausgeklappt ist. Außerdem habe ich nicht geklagt, dass ich nur zwei Zeilen finde, die sich unterscheiden. Zwei spezielle sind mir lediglich in's Auge gefallen.
-
Hallo
Wenn du sehen würdest, dann hättest du in meinen ScreenShots erblickt, dass alles ausgeklappt ist.
Das gälte nur, hätte ich die Beiträge in zeitlicher Reihenfolge gelesen. Tat ich aber nicht.
Außerdem habe ich nicht geklagt, dass ich nur zwei Zeilen finde, die sich unterscheiden.
Da du immer wieder und ausschließlich zwei Zeilen benannst hast, hat das auf mich den Eindruck gemacht, es gäbe für dich nur diese zwei Zeilen. Ist ja auch egal, deine Screenshots habe ich sowieso erst nach meinem vorherigen Posting gesehen und die richtigen Hinweise hast du von dedlfix bekommen.
Tschö, Auge
--
Wenn man ausreichende Vorsichtsmaßnahmen trifft, muss man keine Vorsichtsmaßnahmen mehr treffen.
Lord Vetinary in „Toller Dampf voraus“ von Terry Pratchett
-
-
-
-
-
-
-
-
-
-
-
-
Ich habe gerade mal neugierig testen wollen und festgestellt, dass das Formular die Emaileingabe verifiziert und sobald nach dem "@" ein "" folgt, so wird die Nachricht nicht zugelassen. Von daher erübrigt sich die php -Sicherheitsabfrage m.E.
Frank
-
Ich habe gerade mal neugierig testen wollen und festgestellt, dass das Formular die Emaileingabe verifiziert und sobald nach dem "@" ein "" folgt, so wird die Nachricht nicht zugelassen. Von daher erübrigt sich die php -Sicherheitsabfrage m.E.
Falsch! Mach mal den Google Chrome auf, dann auf Element untersuchen, ändere folgenden Wert von
<input class="form-control" id="email" name="email" placeholder="Email" type="email" required="">auf
<input class="form-control" id="email" name="email" placeholder="Email" type="text" required="">Und schon kann ich es abschicken, wenn du es nicht mit PHP prüfst.
-
Tach!
Ich habe gerade mal neugierig testen wollen und festgestellt, dass das Formular die Emaileingabe verifiziert und sobald nach dem "@" ein "" folgt, so wird die Nachricht nicht zugelassen. Von daher erübrigt sich die php -Sicherheitsabfrage m.E.
Nein, die erübrigt sich nicht, weil Spammer sich nicht für das Formular interessieren und wie der Browser das handhabt. Die schicken den Request einfach so zu dir. Und dabei können eben auch Zeilenumbrüche mitgeschickt werden, die ein normaler Benutzer mit dem Browser gar nicht fabrizieren kann.
dedlfix.
-
Ok ok, Ihr habt mich überzeugt. Ich werde die Eingabe testen. Danke! :-)
-
-
Hallo und guten Abend,
was meinst du mit Zielkontextanpassung und Eingabe filtern?
Der Kontext ist hier die mail()-Funktion. Solange du da keine HTML-Mail schickst, ist das Format dieser Mail Plaintext. Da gibt es nichts, was angepasst werden muss.
Bie
$betreff="Kontaktformular-mehlhop.com, Nachricht von ".$_POST[name];bin ich anderer Meinung als Du. Ich hoffe, dass ich mich nur irre. Aber mMn kann man hier über den ungefilterten Post-Parameter beliebige Header einschleusen.Der Post-Value landet im Subject-Header, und der lässt sich dann durch die übermittelten Daten beliebig manipulieren. Das läuft unter "Mail Injection".
Bitte korrigiere mich, wenn ich da zu sensibel bin.
Und bitte erklär mir nochmal ganz kurz, seit wann PHP nicht druckbare Zeichen filtert aus dem Eingabedaten.
Grüße
TS-
Tach!
Bie
$betreff="Kontaktformular-mehlhop.com, Nachricht von ".$_POST[name];bin ich anderer Meinung als Du. Ich hoffe, dass ich mich nur irre. Aber mMn kann man hier über den ungefilterten Post-Parameter beliebige Header einschleusen.Nö, dazu braucht mal Zeilenumbrüche, und die werden von PHP zu Leerzeichen konvertiert.
Der Post-Value landet im Subject-Header, und der lässt sich dann durch die übermittelten Daten beliebig manipulieren. Das läuft unter "Mail Injection".
Theoretisch ja, aber ohne Zeilenumbrüche läuft da nichts.
Und bitte erklär mir nochmal ganz kurz, seit wann PHP nicht druckbare Zeichen filtert aus dem Eingabedaten.
Wie kann ich denn einen Zeitpunkt erklären? Wie auch immer, den kenne ich nicht. Aber das macht PHP schon seit ein paar Jahren, als noch Version 4.x aktuell war.
dedlfix.
-
Hallo und guten Abend,
Wie kann ich denn einen Zeitpunkt erklären? Wie auch immer, den kenne ich nicht. Aber das macht PHP schon seit ein paar Jahren, als noch Version 4.x aktuell war.
Ach, deshalb kann man schon seit Jahren keine mehrzeiligen Textareas mehr mit PHP verarbeiten? :-P
Überleg bitte nochmal, WER da eventuell was konvertiert.
**Ich bleibe bei meiner Aussage aus dem obigen Thread: **
Bei
$betreff="Kontaktformular-mehlhop.com, Nachricht von ".$_POST[name];kann man über den ungefilterten Post-Parameter beliebige Header einschleusen.Grüße
TS-
Tach!
Ach, deshalb kann man schon seit Jahren keine mehrzeiligen Textareas mehr mit PHP verarbeiten? :-P
Nicht PHP überall, sondern ...
Überleg bitte nochmal, WER da eventuell was konvertiert.
... die Funktion mail() macht das mit den beiden Parametern $to und $subject. War unpräzise ausgedrückt, aber für mich war der Kontext die mail()-Funktion und nicht PHP insgesamt.
dedlfix.
-
Hallo und guten Morgen,
Ach, deshalb kann man schon seit Jahren keine mehrzeiligen Textareas mehr mit PHP verarbeiten? :-P
Nicht PHP überall, sondern ...
Überleg bitte nochmal, WER da eventuell was konvertiert.
... die Funktion mail() macht das mit den beiden Parametern $to und $subject. War unpräzise ausgedrückt, aber für mich war der Kontext die mail()-Funktion und nicht PHP insgesamt.
Ok, einverstanden. Die mail()-Funktion übernimmt für $to und $subject eine gewisse Datenprüfung (auf die ich mich nie verlassen würde). Für "From: ", was ja über die Zusatzheader kommen müsste, allerdings nicht.
Ich habe es jetzt aber nicht selber nachgeprüft, was da "innen drin" passiert. Ist das Verhalten dokumentiert?
Grüße
TS-
Tach!
Ich habe es jetzt aber nicht selber nachgeprüft, was da "innen drin" passiert. Ist das Verhalten dokumentiert?
Im öffentlich einsehbaren Code ja ;) - in der Dokumentation leider nicht.
Ich kann mir aber nicht vorstellen, dass diese Zeichenersetzung in den beiden als Einzeiler konzipierten Parametern zu einem Problem führen könnte, das eine Entfernung dieser Ersetzung rechtfertigt.
Was ich aber grad nicht beantworten kann, ist die Frage, ob mail() überlange Einträge in diesen beiden Parametern regelkonform umbricht. Aber wenn nicht, kann man als Verwender im Problemfall auch nichts weiter machen, als mail() zu meiden.
dedlfix.
-
-
-
-
-
-
-
-