WBCE CMS – Way Better Content Editing.
You are not logged in.
Hallo zusammen,
mir ist gerade aufgefallen, dass sich sämtliche Formulare auf meiner Seite nicht mehr abschicken lassen. Es macht keinen Unterschied, ob ich den Outputfilter im Admin-Bereich auf Relative Urls oder nicht einstelle.
Im Quelltext steht immer der relative Pfad:
[== HTML ==]
<form name="form_58" enctype="multipart/form-data" action="/pages/verzeichnis/dateiname.php#wb_section_58" method="post">
Im Augenblick habe ich die neueste Version 1.3.11 installiert. Bei der vorherigen 1.3.9 hatte ich das Problem auch.
Wo könnte ich noch suchen, woran das liegt?
Last edited by florian (03.11.2017 19:01:41)
Offline
Was genau meinst Du mit "lassen sich nicht mehr abschicken"? Kommt eine Fehlermeldung, oder kommen die Mails nicht an? Werden die Eingaben dennoch im Backend gespeichert?
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Nein, nach dem Abschicken springt er einfach auf die Hauptseite. In der Url steht dann https://www.meinedomain.de/index.php#wb_section_58
Das Formular wird dabei nicht bearbeitet.
Offline
Verwendest Du shortURL?
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Ähh, ShortURL? Was ist das? ;-)
Offline
shortURL bewirkt, dass in der Adresszeile im Browser deinedomain.tld/formular/ statt deinedomain.tld/pages/formular.php steht.
Zu Deiner Angabe im ersten Post: Das ist m.E. normal so.
Hast Du eine .htaccess im root? wenn ja, was steht da drin?
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
RewriteEngine On
RewriteCond %{HTTP_HOST} ^domain.tld [NC]
RewriteRule ^(.*)$ http://www.domain.tld/$1 [L,R=301]
Ich zensier es mal nicht ... ist im Grunde ja egal, die Seite ist eh öffentlich. Aber, ich versteh garnicht, warum der https Teil dort fehlt ...
Hab die URL jetzt doch mal rausgenommen -fm
Last edited by florian (03.11.2017 19:02:25)
Offline
Daran könnte es liegen. Ändere das http:// doch mal in https:// und versuche es dann nochmal. (Wichtig, Cache leeren und/oder anderen Browser benutzen. Insbesondere Firefox setzt sich über solche Änderungen gern mal hinweg.)
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
So, habe jetzt alles probiert, sogar den Inhalt der .htaccess gelöscht etc. Es ändert nichts an dem Verhalten der Formulare.
Last edited by ice (03.11.2017 18:29:33)
Offline
Es könnte dann eventuell ein Rechteproblem sein. Kannst Du bitte mal schauen, was bei den Grundeinstellungen für Verzeichnis- und Dateirechte hinterlegt sind (sollte 0644 / 0755 sein) und per FTP prüfen, welche Rechte für das Verzeichnis und die Dateien /modules/mpform vergeben sind?
Nochwas, läuft da PHP als CGI oder als Apache-Modul?
Du kannst mir auch einen FTP-Zugang einrichten und mir die Daten per PM oder an support@wbce.org zusenden, dann schaue ich mal, ob ich was finde.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Es scheint irgend ein grundsätzliches Problem mit mpform und SSL und/oder All-Inkl zu geben. Ich habe exakt das selbe Verhalten auf einer Testseite reproduzieren können. Mit Miniform und Classic Form tritt das Problem nicht auf.
Ich mache mal einen Issue auf Github auf.
Um zu vermeiden, dass Anfragen verloren gehen, solltest so schnell wie möglich Du vorübergehend auf der Isetta-Seite das mpform durch miniform ersetzen oder es erstmal offline nehmen.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Das Problem ist, ich habe viel zu viele Formulare. Neben den 2 Kontaktformularen habe ich ein Mitgliedsaufnahmeformular und jetzt sollte eigentlich das Anmeldeformular für das Jahrestreffen für nächstes Jahr online kommen. Das sind Formulare, die macht man nicht mal eben neu, dazu sind da viel zu viele Felder drin.
Sorry, war grad essen. All-inkl ist richtig, PHP läuft als CGI mit PHP 5.6.
Last edited by ice (02.11.2017 18:01:44)
Offline
Das komische ist aber, die Formulare haben ja funktioniert bis 17.10. Danach habe ich keine E-Mails mehr von den Formularen erhalten. Leider bekomme ich von den Clubmitgliedern selten Rückmeldungen, wenn was nicht funktioniert. Auf HTTPS habe ich aber schon im April umgeschaltet, da funktionierten die Formulare noch. Irgendwann im September / Oktober hatte ich auf WBCE 1.3 umgestellt, weiß den genauen Tag aber nicht mehr.
Last edited by ice (02.11.2017 18:07:01)
Offline
Es liegt an 1.3. Leider. Mit 1.2 tritt das Problem nicht auf.
Ich gebe das Problem an norhei und mrbaseman weiter, da ich weder die konkrete Ursache weiß, noch einen Workaround liefern kann.
Ich bitte um Entschuldigung für die Probleme. Bis auf weiteres hilft leider nur ein Rollback auf 1.2 (sofern eine Sicherung vorhanden ist) oder das Abschalten der Formulare. Ich hoffe sehr, dass sich kurzfristig eine Lösung findet, kann das aber nicht versprechen.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
Ok Florian, vielen Dank für Deine Hilfe / Unterstützung. Ich hoffe dann einfach mal auf eine baldige Lösung des Problems.
Die kleineren, einfachen Formulare ersetze ich gerade durch das miniform Modul. Die großen (4 Stück) bleiben erstmal offline, da habe ich in der Vergangenheit viel, viel Zeit hineingesteckt, damit die responsive wurden.
Offline
Zur allgemeinen Verunsicherung: Ich habe heute eine Site von WBCE Version 1.1. auf die aktuelle 1.3. gebracht. Dort ist die mpForm Version 1.3.3 installiert und funktioniert. Aufruf über https.
Offline
Ja, scheint irgendwie vom Hoster abhängig zu sein.
Bei zwei getesteten tritt das Problem auf, bei einem weiteren nicht.
Der Modulentwickler ist schon an der Sache dran.
@thanks: Kannst Du mir per PM mal den Link zum Formular, das funktioniert, mitteilen?
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
An den Schlauberger, der gerade mein Kontaktformular getestet und geschrieben hat "geht doch":
Wie ich bereits geschrieben habe, habe ich alle kleinen Kontaktformulare durch das miniform Modul ersetzt (ausgetauscht!!!), da dass mpform Modul im Augenblick nicht funktioniert. Meine großen Formulare mit mpform (die nicht funktionieren) sind vorübergehend versteckt. Deswegen habe ich oben jetzt den Link zu dem Kontaktformular gelöscht, weil dort kein mpform Formular mehr zu finden ist.
Last edited by ice (03.11.2017 18:38:44)
Offline
Ich habe die Links in den anderen Posts entfernt, scheint ja doch zu viele Scherzkekse da draußen zu geben.
mrbaseman ist an der Sache dran. Er hatte mir heute schon eine Zwischenversion zum Testen gegeben, die aber leider noch keine Lösung brachte.
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
ice
Es steht ein Patch bereit, der das Problem löst.
https://forum.wbce.org/viewtopic.php?pid=15047#p15047
Sorgen sind wie Nudeln: man macht sich meist zu viele.
Offline
ice
Hallo,
ich hab gerade Version 1.3.12 auf github veröffentlicht.
norhei hat dafür einen Fix geliefert, der das hier diskutierte Problem wohl behebt. Was der Fix mit https zu tun hat, verstehen wir im Moment noch nicht genau (hat vermutlich was mit output filtern zu tun)...
Könnten diejenigen, die (je nach Provider) in das Problem reingelaufen sind, diese Version bitte testen und Feedback geben?
Offline
ice, thanks
Hallo zusammen, bin nicht zuhause. Hab aus der ferne den fix hochgeladen und ein formular testweise abgeschickt. Hat funktioniert! Morgen werde ich das nochmal gründlich testen.
Vielen Dank für eure wirklich schnelle Reaktion und Hilfe! Echt toll!
Offline
Also, der Fix funktioniert. Habe jetzt schon wieder jede Menge E-Mails (= erfolgreiche Formularübermittlung) von Neumitgliedern bekommen. Ich danke nochmals für den schnellen und erfolgreichen Fix!
Offline
florian
Analyse des mpForm Problems unter WBE 1.3
ich bin hier noch auf was gestoßen: In WBCE 1.3 enthält modules/output_filter/filter_routines.php die folgende Funktion:
function getOutputFilterSettings() {
//fetch settings whith default values
$settings = array(
'sys_rel' => Settings::Get("opf_sys_rel", 0),
'email_filter' => Settings::Get("opf_email_filter", 0),
'mailto_filter' => Settings::Get("opf_mailto_filter", 0),
'at_replacement' => Settings::Get("opf_mailto_filter",'(at)'),
'dot_replacement' => Settings::Get("opf_mailto_filter",'(dot)')
);
return $settings;
}
was zwar in modules/output_filter/filters/filterEmail.php nicht mehr verwendet wird, aber von mpForm genommen wurde, um die Ersetzungen dieses Filters wieder rückgängig zu machen. Falsch ist hier, dass der Wert für opf_mailto_filter auch für at_replacement und dot_replacement zurückgeliefert wird. In dem Patch von NorHei wird das Array für WBCE-Versionen die die Settings-Klasse unterstützen nun grundsätzlich fest verdrahtet als
$filter_settings = array(
'sys_rel' => 0,
'email_filter' => 0,
'mailto_filter' => 1,
'at_replacement' => Settings::Get('opf_at_replacement', '(at)') ,
'dot_replacement' => Settings::Get('opf_dot_replacement', '(dot)')
);
Abgefragt wird später der Wert für email_filter und eine Rückersetzung findet nur dann statt wenn dieser zu TRUE evaluiert wird, sprich: überhaupt nie, da der Wert fest auf 0 gesetzt ist.
Was lief schief mit mpForm unter WBCE 1.3?
at_replacement und dot_replacement enthielten den Wert für mailto_filter (also 0 oder 1) und immer dann, wenn email_filter aktiviert war, wurden also alle Nullen oder Einsen durch '@' bzw. '.' "zurück"-ersetzt. Das passiert überall in den submittierten Feldern, z.B. auch in der Submission ID und allen Field IDs usw. Dass die so verfälschten Daten nicht ordentlich weiter verarbeitet werden können dürfte einleuchtend sein. Gerade wenn die Submission_id zwischen Erzeugen des Formulars und der Auswertung nach dem Abschicken verändert wurde, geht mpform davon aus, dass jemand versucht das Formular zu hacken. In dem Fall macht es Sinn, einenm potentiellen Angreifer nicht auch noch mit der Nase darauf zu stoßen, an welchen Stellen das Modul ihm genau auf die Finger schaut. Deswegen gibt es an der Stelle auch keine super detaillierte Fehlermeldung. Der Angreifer wird einfach zurück umgeleitet auf die Start-Seite.
Warum genau WBCE 1.3 und nicht ältere Versionen?
In älteren Versionen hatte man die von WB Classic stammende Funktion bereits entfernt oder es wurden zumindest die Settings noch nicht verwendet. Erst in 1.3 kam diese Funktion wieder zurück, wurde aber mit der Settings-Klasse fehlerhaft implementiert.
Warum funktionierte der Fix?
Weil die Ersetzungen gar nicht mehr stattfanden. Als kleiner Nebeneffekt sind die Ersetzungen '(at)' und '(dot)' oder wie auch immer sie konfiguriert sind, in den abgeschickten Daten enthalten. [Edit:] Das betrifft zum Beispiel Empfänger Adressen zwischen denen der Besucher in einer Liste auswählen kann, wenn die email Adressen dabei in Klartext dargestellt werden und der Output Filter bei der Darstellung des Formulars drüber gelaufen ist. Benachrichtigungsmails an Adressen ohne '@' Zeichen können dann natürlich nicht ankommen. Das war übrigens wohl auch in vorigen Versionen von WBCE so, nur wurde der Code aus dem Fix von Norhei erst später abgefragt, wenn alle anderen Varianten um zu ermitteln welche Ersetzungen eventuell zurückzunehmen sind schon fehltgeschlagen waren. Da war das eigentlich als Notnagel gedacht um $filter_settings wenigstens irgendwie zu belegen. Dass damit gar nie Ersetzungen zurückgenommen wurden und das bisher nicht aufgefallen war, zeigt dass es sich hierbei um sehr selten auftretende Fälle von Konfigurationen handelt, die vielleicht unter WBCE noch niemand eingesetzt hatte.[/Edit]
Was hat das ganze mit https zu tun?
Vermutlich gar nichts. Es hat damit zu tun was für den Email-Filter eingestellt ist. Bei Neuinstallationen ist er aktiviert. Vielleicht war er er es bei der ein oder anderen "Testinstallation" nicht und man hat es fälschlicherweise mit https in Verbindung gebracht - oder wir haben im Installer noch ein weiteres Problem, bei dem die Settings mit und ohne https in der URL unterschiedlich befüllt werden, insbesondere opf_email_filter, was dann in der Folge dazu führt, dass die fehlerhafte Implementierung für at_replacement und dot_replacement im einen Fall verwendet wird und im anderen Fall Ersetzungen einfach unterbleiben.
Dafür, dass es nicht mit https zusammenhängt spricht auch, dass zudem eine Abhängigkeit vom jeweiligen Hoster vermutet wurde. Da Produktionsumgebungen nach dem Upgrade auf 1.3 nicht mehr funktioniert haben, musste eine schnelle Lösung her. Da das Problem schwer zu greifen war hat man nach Erklärungen gesucht und leider an manchen Stellen die falschen Schlüsse gezogen. Der Fix schien auf den ersten Blick zu funktionieren und die Produktonsumgebungen waren damit wieder verfügbar. Trotzdem ist ein FIx dessen WIrkungsweise man nicht versteht eine ungute Sache und Quelle für neue unangenehme Überraschungen. Genau das ist der Grund, warum ich der Sache noch ausführlicher nachgegangen bin.
Wie geht es jetzt weiter?
Mein Vorschlag wäre, dass die Funktion getOutputFilterSettings() in WBCE 1.3 gefixt wird (siehe PR #316). Eine korrigierte mpform-Verson hänge ich diesem Post an und würde sie dann als 1.3.15 auf Github veröffentlichen, wenn ihr sie getestet habt.
Last edited by mrbaseman (29.11.2017 10:37:27)
Offline
Ich würde gerne helfen. Kann ich Deine Version bei mir in meiner Produktivumgebung testen oder ist mit größeren Problemen zu rechnen?
Offline