[Gelöst] mpform Fehlermeldung nach dem Senden

[tortellini62]

Hi,

habe WebsiteBaker nach der Umstellung auf php7.2 neu aufgesetzt und die Seiten mit neuem Template (responsiv) erstellt. Für die Kontaktseite habe ich das Mailmodul von mpform installiert. Hatte ich vorher auch schon und hat bisher auch super funktionniert.
Jetzt habe ich das Problem, dass ich nach dem Absenden auf einer 403 Seite lande mit dem Hinweis:
Forbidden
You don't have permission to access /pages/ on this server.
Die Mail wird auch nicht versendet, da im Backend nichts angezeigt wird. Habe PHP-Mail sowie auch SMTP-Versand probiertz, alles ohne Erfolg. Die index.php Rechte sind auf 755 eingestellt. Ich habe mich auch schon mit dem Provider-Support (one.com) in Verbindung gesetzt, leider ohne konstruktive Hilfe. Hat jemand eine Ahnung wie ich den Fehler weg bekomme?

Danke für eure Hilfe

Tortellini

[hgs]

Ein Link zu der Seite ist für die aktiven Helfer bestimmt ein guter Weg.
Die können da schon immer viel sehen, was wir "DAUS´s" gar nicht wahrnehmen. 

[Martin Hecht]

Anhand der Fehlerbeschreinung kann ich empfehlen: Kontrollier mal, ob bei den Workflow Einstellungen alles passt. Das Pages-Directory müsste ja zugreifbar sein. Stimmt WB_URL und WB_PATH? oder landet die Weiterleitung hier im falschen Pfad?

[tortellini62]

Hallo,

Ok, da gebe ich euch recht, der Weblink ist immer hilfreich. Hier also die Adresse: http://www.schmittenhof-schroecken.at

Gruß

T.

[tortellini62]

Hallo,

Anhand der Fehlerbeschreinung kann ich empfehlen: Kontrollier mal, ob bei den Workflow Einstellungen alles passt. Das Pages-Directory müsste ja zugreifbar sein. Stimmt WB_URL und WB_PATH? oder landet die Weiterleitung hier im falschen Pfad?

Sorry, da musst man mir ein bisschen auf die Sprünge helfen. Wo finde ich die Einstellungen für WB_URL und WB_PATH?
Die Navigation auf alle Seiten funktioniert problemlos. Habe eine Dankesseite eingerichtet und in der Navigation auf nicht sichtbar gestellt. Auch ohne diese Seite das gleiche Ergebnis.

Grüße

Tortellini62

[jacobi22]

@ Martin: schau ich mir den Code an in evalform.php  ~ Ln 258ff
bin ich eher bei ASP, allerdings weiß ich nicht Bescheid mit MPFORM_SKIP_ASP
Permissions schließ ich aus, weil die anderen Seiten ja kein Problem zeigen

@tortellini62: schau bitte mal unter AdminTools -> Captcha-Einstellungen -> Erweiterter-Spam-Schutz (ASP) Einstellungen
ggf mal wechseln.

Code: [Select]

if(ENABLED_ASP AND (!(defined('MPFORM_SKIP_ASP')&&(MPFORM_SKIP_ASP))) AND (
               // form faked? Check the honeypot-fields.
            (     !isset($_POST['submitted_when'.$section_id])
               OR !isset($_SESSION['submitted_when'.$section_id]))
               OR ($_POST['submitted_when'.$section_id] != $_SESSION['submitted_when'.$section_id])
               OR (!isset($_POST['email'])    OR $_POST['email'])
               OR (!isset($_POST['homepage']) OR $_POST['homepage'])
               OR (!isset($_POST['comment'])  OR $_POST['comment'])
               OR (!isset($_POST['url'])      OR $_POST['url'])
            )) {
                $sUrlToGo = WB_URL.PAGES_DIRECTORY;
                if(headers_sent())
                  $admin->print_error($MESSAGE['GENERIC_SECURITY_ACCESS']
                  .' (ID_CHECK) '.__FILE__.':'.__LINE__,
                  $sUrlToGo);
                else
                  header("Location: ". $sUrlToGo);
                exit(0);
            }

[evaki]

Nach dem Absenden des Formulars gibts:

Code: [Select]

http://www.schmittenhof-schroecken.at/pages/#Sec10

[Martin Hecht]

Hallo,

Bei dem Seitenaufruf fehlt irgendwie kontakt.php vor dem '#'. Der Section Anchor wiederum ist da und korrekt, das pages-Directory passt auch mit der Ausgabe des unausgefüllten Formulars zusammen. Das ist irgendwie merkwürdig.

@tortellini62: die URL hat glaub ich schon geholfen. Die Konstanten werden bei der Installation von WB festgelegt. WB_URL  wäre in diesem Fall die Domain. Man könnte WB auch in einem Ordner auf dem Webserver installieren und in dem Fall käme nach der Domain noch der Pfad zur WB-Installation. Wenn es einen solchen Pfad gäbe, dieser aber in der Konstanten nicht drin stehen würde, dann würde manches nicht funktionieren. Dabei könnte man auch in einem Ordner landen, der einen Permission Denied-Fehler auswirft, aber ich glaube, das können wir ausschließen. WB_PATH geht in eine ähnliche Richtung, bezeichnet aber den absoluten Pfad im Dateisystem auf dem Server. Da aber der Pfad dorthin wohl passt ist es unwahrscheinlich, dass wir hiermit ein Problem haben.

Mach mal die Datumsfelder nicht als Pflichtfelder. Ich glaub ich bin da einem Bug im Formular auf der Spur.... ich versteh zwar noch nicht wieso dabei 'kontakt.php' verschluckt wird, aber ich habe eine Ahnung warum das Absenden nicht funktioniert.

 @jacobi22: da der Section-Anchor in der Weiterleitungs-URL noch mit vorkommt, glaube ich dass 258ff auch nicht in Frage kommen. Dort endet $sUrlToGo nämlich auf das PAGES_DIRECTORY (ohne Anchor). Zur Info: MPFORM_SKIP_ASP kann man in constants.php definieren (die vorbereitete Definition ist einfach auskommentiert, man muss sie nur aktivieren) um zu Debuggingzwecken die Sicherheitsprüfunge n zu deaktivieren. Das gibts für FTAN, IDKEY, ASP, Captcha, SubmissionID. Aber mit dem Section Anchor hinten dran, glaube ich nicht dass es einer diesr redirects ist, zumal man auch bei nicht ausgefüllten Pflichtfeldern auf diese URL weitergeleitet wird (es müsste eigentlich dann das Formular neu ausgegeben werden, aber warum das nicht geschieht, sondern der redirect aufs Pages-Directory geht, ist die nächste Frage).

@tortellini62: hast du zufällig mit .htaccess-Files experimentiert, z.B. im Zusammenhang mit ShortURL? eine RewriteEngine im Webserver aktiviert? irgend sowas in dieser Richtung...

Viele Grüße,
Martin

[jacobi22]

ich erinnere mich, das es im Form-Modul auf einigen Servern (z.b. bei mir auf Stato) auch Probleme mit der aus $_SERVER['SCRIPT_NAME'] ermittelten aktuellen Adresse gab. Jetzt wird sie so ermittelt (modules/form/view.php ~Ln 122)

Code: [Select]

$sScriptUrl = WB_URL.PAGES_DIRECTORY.$wb->page['link'].PAGE_EXTENSION ;mit nachfolgendem Schalter für eine mögliche short.php

der Aufbau des Formulars in mpform kommt ja aus der paintform.php

Z. 329
 

Code: [Select]

$sActionAttr = htmlspecialchars(strip_tags($_SERVER['SCRIPT_NAME']));
Z. 341ff

Code: [Select]

if (defined( 'SEC_ANCHOR' )){
                $sSectionAnchor =  '#' . SEC_ANCHOR . $iSID;
            } else {
                $sSectionAnchor = '#'. $iSID;
            }
ist $_SERVER['SCRIPT_NAME'] jetzt leer, bleibt ein #Sec10 über

Wäre (wenn ich denn richtig liege) für tortellini62 zumindest mal einen Versuch wert.


@ Martin: Ein paar andere Sachen, die mir noch aufgefallen sind, vielleicht was für eine der nächsten Versionen?):

- die beiden Felder Anreise bzw Abreise zeigen einen Stern für required und bekommen beide auch die CSS-Klassen dafür. Beide Felder werden aber beim Versand nicht geprüft, hier fehlt m.E. ein required="required" bzw in HTML 5 ein einfaches required im jeweiligem Input-Feld

- der Link zum Kalenderblatt hat einen doppelten Slash vor dem Bildnamen -> http://www.domain.de/modules/mpform/images//cal.png
Nicht weiter tragisch, nur für Martin zur Kenntnisnahme

[tortellini62]

Hallo,

vielen Dank erst einmal für euer intensives Interesse und eure Vorschläge.

Der Vorschlag von jacobi22 hat nun schon ein wenig geholfen. Es war der selektierte ASP in den Mail Optionen.
Ich werde jetzt zwar an die kontakt.php#Sec10 weitergeleitet, jedoch erscheint kein Sendebestätigung und die Seite wird nach dem Klick auf Senden ohne CSS dargestellt. Auch die Dankesseite bringt nichts. Im Backend werden auch keine gendeten Mails angezeigt.
Habe beide Versandarten (SMTP & PHP-Mailer) ausprobiert, jedoch immer das gleiche Ergebnis.
Jetzt bin ich genauso sprachlos wie vorher.

Grüße

Tortellini62

[evaki]

Code: [Select]

Insecure transition from HTTP to HTTPS in form post
Vulnerability description
This form is served from an insecure page (http) page. This page could be hijacked using a Man-in-the-middle attack and an attacker can replace the form target.
Affected items
/pages/kontakt.php
The impact of this vulnerability
Possible information disclosure.

How to fix this vulnerability
The form should be served from a secure (https) page.

[jacobi22]

offensichtlich wird per .htaccess eine Umleitung auf https erzwungen, in der config.php wurde aber die WB_URL aber nicht auf https geändert
Noch schlimmer wäre, wenn in der index.php des Templates alle Pfade hardcoded gesetzt wurden.

Der Post von Evaki ist dann das Ergebnis dieser Aktion, weil die Seite durch Einbindung der http-Link nicht mehr sicher ist, wird der Versand auch nicht sicher ausgeführt. Behebe das bitte erst einmal, dann das nächste Problem

[tortellini62]

Hallo Leute,

habe den Fehler gefunden. Nach dem mich evaki & jacobi22 darauf gebracht haben, dass es mit https zu tun hat, hatte es geschnakelt. Es läuft jetzt alles bestens. Vielen Dank für eure Unterstützung. Die Umstellung in der config.php auf https war die Lösung.

PS: Es funktioniert auch, wenn man in den Optionen auf relative Pfade umstellt.

Beste Grüße

Tortellini62

PS: Wie kann ich denn den Post als Lösung oder gelöst markieren?

[jacobi22]

PS: Wie kann ich den den Post als Lösung oder gelöst markieren?

das geht nur max 15 min nach dem Schreiben des jeweiligen Postings oder mit Hilfe eines Admins

[Martin Hecht]

Hallo,

offensichtlich wird per .htaccess eine Umleitung auf https erzwungen, in der config.php wurde aber die WB_URL aber nicht auf https geändert

na, dann lag ich mit meinen Vermutungen bzgl. WB_URL und redirects gar nicht so weit daneben. Aber die Weiterleitung war nur dann aktiv, wenn man Daten per "POST"-Methode geschickt hat. Die Seite ganz normal mit Get über http abzurufen hat ja funktioniert.

ich erinnere mich, das es im Form-Modul auf einigen Servern (z.b. bei mir auf Stato) auch Probleme mit der aus $_SERVER['SCRIPT_NAME'] ermittelten aktuellen Adresse gab. Jetzt wird sie so ermittelt (modules/form/view.php ~Ln 122)

Code: [Select]

$sScriptUrl = WB_URL.PAGES_DIRECTORY.$wb->page['link'].PAGE_EXTENSION ;mit nachfolgendem Schalter für eine mögliche short.php

ok, schau ich mir mal an.

Code: [Select]

$url = $wb->page_link($wb->page['link']);
wie in der include.php von show_menu2 ist vielleicht noch besser. Das liefert das gleiche Ergebnis und sollte mal an der page_link-Methode eine Verbesserung stattfinden, würde das Modul davon profitieren, da es die vom Core bereitgestellte Methode benutzt.

@ Martin: Ein paar andere Sachen, die mir noch aufgefallen sind, vielleicht was für eine der nächsten Versionen?):

- die beiden Felder Anreise bzw Abreise zeigen einen Stern für required und bekommen beide auch die CSS-Klassen dafür. Beide Felder werden aber beim Versand nicht geprüft, hier fehlt m.E. ein required="required" bzw in HTML 5 ein einfaches required im jeweiligem Input-Feld

ok, da schau ich danach und gestern ist mir auch aufgefallen, dass der Feldtyp 'date' es in evalform gar nicht berücksichtigt wird. Das hat mich etwas stutzig gemacht und daher hab ich vorgeschlagen das mal nicht als Pflichtfeld zu machen. Wahrscheinlich ist es mit einem der generellen else-Zweige schon abgedeckt, aber der Code ist da zugegebenermaßen ziemlich verschachtelt. Muss ich mir nochmal anschauen, ob das da alles ganz richtig geprüft wird.

- der Link zum Kalenderblatt hat einen doppelten Slash vor dem Bildnamen -> http://www.domain.de/modules/mpform/images//cal.png

lieber einer zu viel als einer zu wenig - ok, schau ich mir an

Gruß Martin

[jacobi22]

mit dem Datumsfeldern... Ich denk, das hat sich selbst repariert   
hab das vorhin mit der erfolgten Korrektur noch einmal probiert, da funktionierte die Prüfung.
Er ist wohl mit dem Umschaltfehler vorher garnicht bis zur richtigen Formularprüfung gekommen. Die oberen Felder wurde ja mit dem required schon vom Browser abgedeckt, daher mußte man die ja eh ausfüllen, um was abschicken zu können.

[Martin Hecht]

Hallo,

die Vorgeschlagenen Verbesserungen sind in Relese 1.3.28 mit drin. (required-Option auch beim Feldtyp Kalender, vermeiden von doppelten Slashes, Fallback falls SCRIPT_NAME nicht gesetzt ist).

DIe Prüfung, ob das Datumsfeld ein Kalender ist oder nicht ist bisher über einen allgemeinen Zweig serverseitig erfolgt, der alle Feldtypen abarbeitet, die keine Sonderbehandlung benötigen. In sofern war da nichts zu reparieren, nur eine Neuerung aus einem der letzten Releases auch für diesen Feldtyp noch nachzuziehen.

Grüße,
Martin

@tortellini: bitte beachte dass man die Zip-Dateien von Github nicht direkt als Modul hochladen kann. Man muss sie erst "umpacken": Einmal lokal entpacken, in den dabei erstellten Ordner reinwechseln und den darin enthaltenen Inhalt wieder einpacken - oder einfach warten bis die Version im Addons Repo bereitliegt.