IP-Sperre bei der Formularverarbeitung - Frage zur Modul-Programmierung

[thorff]

Hi, wie im Titel dieses Threads bereits erwähnt, möchte ich eine IP-Sperre realisieren, die verhindert, dass man mit derselben IP ständig dasselbe Formular absenden kann. Bei der Realisierung gibt es einige Schwierigkeiten und ich hoffe, hier im Forum Hilfe zu erhalten.

Zum Hintergrund: Die Formulare einiger TL-Websites, die ich betreue, wurden von einem "Spaßvogel" angegriffen, indem er diese automatisiert und befüllt mit reinem Müll zigtausendfach abgesendet hat. Ich habe nun die Sicherheitsfrage eingefügt, aber - bitte korrigiert mich, wenn ich mich hier täusche - so richtig sicher scheint mir die nicht zu sein. Die Fragen unterscheiden sich nur minimal (z. B. "Was ist die Summe aus 7 und 5", "Bitte rechnen Sie 4 plus 8", "Bitte addieren Sie 3 und 8"), sodass es doch in kürzester Zeit machbar ist, automatisiert die richtige Antwort zu ermitteln und die Sicherheitsabfrage auszuhebeln. Hat man das einmal gemacht, kann man den Angriff locker auf alle normalen TL-Seiten anwenden.

Ein grafisches Captcha einzubinden ist sicher eine Option, aber das müsste dann schon eines sein, das aus Gründen der Barrierefreiheit auch vorgelesen werden kann und allgemein finde ich Captchas für Laien etwas verwirrend. Angeblich hat man durch Verwendung von Captchas außerdem mit Benutzerabbrüchen vor dem Versenden von Formularen zu rechnen. Ich möchte deshalb auf ein richtiges, grafisches Captcha verzichten.

Jedenfalls halte ich die IP-Sperre für eine gute Idee.

Zum konkreten Programmierproblem:
Damit es updatesicher ist, möchte ich die vorbereiteten TL-Hooks verwenden, es bietet sich hier "processFormData" an. Da dieser Hook allerdings nach dem Versenden der Daten per E-Mail bzw. dem Speichern in die DB stattfindet, ist das, was ich abfangen möchte, bereits passiert.

Ich könnte nun die Verarbeitung der Formulardaten (per Mail senden oder speichern) auf mein Modul auslagern, sodass all dies in meiner per Hook eingebundenen Funktion stattfindet. Das möchte ich eigentlich aber nicht machen, da es unschön ist, hier quasi den identischen Code zur Verarbeitung redundant zu haben.

Meine Lösung wäre es nun, das Formular so einzustellen, dass es von alleine die Daten gar nicht verarbeitet und mittels weiterer Einstellungsfelder so zu definieren, dass es nach der IP-Prüfung verarbeitet wird. Ich würde also das Häkchen bei "Eingaben speichern" und "per E-Mail senden" NICHT setzen und dafür die Häkchen bei neuen Feldern namens "Eingaben nach IP-Prüfung speichern" oder "nach IP-Prüfung per E-Mail senden" setzen.

Es würde also nichts passieren, bevor meine eigene Funktion über den Hook aufgerufen würde. Nun könnte die Funktionalität zur IP-Prüfung stattfinden.

Und nun kommt der Clou: Ich möchte nun gerne - sofern die IP akzeptiert wird - den gesamten Verarbeitungsprozess des Formulars erneut aufrufen, dann allerdings die entsprechenden Flags für "Eingaben speichern" oder "per E-Mail senden" setzen. Bei diesem erneuten Aufruf würde die per Hook eingebundene Funktion natürlich nichts mehr machen.

Diese Idee scheint mir der minimalste funktionierende Eingriff zu sein.

Meine Frage ist nun: Wie kann ich denn aus der per Hook eingebundenen, eigenen Funktion die Verarbeitung des Formulars - also die Funktion "processFormData" in der Datei "Form.php" - erneut aufrufen? Ich dachte schon daran, per header() die aktuelle URL nochmal aufzurufen, aber da kann ich die POST-Daten nicht übermitteln... Hat jemand eine Idee?!?

Und falls mir jemand plausibel erklären kann, weshalb der ganze Aufwand unnötig ist, wäre ich auch dankbar. Aber ich kann mir einfach nicht vorstellen, dass die Sicherheitsabfrage wirklich sicher ist.

Danke im Voraus!

[do_while]

Hallo thorff,

da hast Du wohl etwas falsch verstanden. Der HOOK wird ausgeführt, nachdem der User den Abschicken-Button geklickt hat, aber vor dem Versenden der Mails. Sonst gäbe eine Verarbeitung der Daten ja wenig Sinn, wenn die unbearbeiteten Daten dann gemeldet werden.

Das ist jetzt ungetestet, aber Du kannst in diesen Hook Deinen IP-Check einbauen. Nur gibt der Hook keinen Rückgabewert zurück, also muss man schauen, wie man sonst das Absenden der Mail verhindern kann. Evtl. kannst Du die Zieladresse auch einfach im Hook auf eine Dummy-Adresse umlenken, dann geht die Mail gleich ins Nirwana.

[deerwood]

Hallo do_while, thorff,

da hast Du wohl etwas falsch verstanden. Der HOOK wird ausgeführt, nachdem der User den Abschicken-Button geklickt hat, aber vor dem Versenden der Mails. Sonst gäbe eine Verarbeitung der Daten ja wenig Sinn, wenn die unbearbeiteten Daten dann gemeldet werden.

thorff hat Recht, der HOOk 'processFormData' wird "after the act" ausgeführt, dann ist die email bereits versendet bzw. sind die Daten schon in der DB gelandet. Nach dem Hook werden nur noch Log-Einträge gemacht.

Ein Weg wäre eventuell den Hook 'validateFormField' zu nutzen, sich ein Feld herauszupicken und das auf fehlerhaft zu setzen, wenn die IP nicht akzeptiert wird. Dann wird das Formular nicht weiterverarbeitet.

LG, Georg

[thorff]

Hi zusammen!

Ich habe das ganze jetzt tatsächlich mit dem Hook "validateFormField" gelöst.

Im Prinzip ging es so:

1. Neues Formularfeld "IP-Check" hinzugefügt
2. Hook "validateFormField" mit dem Aufruf einer von mir hierfür erstellten Funktion registriert
3. In dieser Funktion prüfen, ob das Widget eine Instanz eben dieses IP-Check-Feldes ist
4. Wenn nicht, wird gar nichts gemacht, wenn doch, findet hier die gesamte IP-Check-Routine statt. Es wird also in der eigens dafür angelegten Tabelle nach der IP gesucht und falls sie nicht vorhanden ist, wird sie eingetragen. Die alten Einträge (anhand des Timestamps zu identifizieren) werden natürlich zuerst gelöscht.
5. Wurde festgestellt, dass die IP bereits eingetragen ist, wird für das IP-Check-Feld eine passende Fehlermeldung gesetzt

Hat so wunderbar funktioniert, danke!

[thorff]

Sonst gäbe eine Verarbeitung der Daten ja wenig Sinn, wenn die unbearbeiteten Daten dann gemeldet werden.

Ja, genau darüber habe ich mich gewundert, als ich diesen Hook nutzen wollte.

[Antipitch]

Moin,

Ja, genau darüber habe ich mich gewundert, als ich diesen Hook nutzen wollte.

der Name des Hooks ist diesbezüglich vielleicht etwas irreführend, tatsächlich hat er aber nichts mit einer eventuellen TL-internen Weiterverarbeitung der Daten zu tun. Im Entwicklerhandbuch ist davon auch nicht die Rede. Sehr wohl steht dort allerdings, dass der Hook keine Rückgabe erwartet, eine Beeinflussung der Weiterverarbeitung wäre demnach eine ziemlich erstaunliche Sache...


cheers
Antipitch

PS: Eine Umstellung wäre sicher ein relativ leicht zu erzielender Mehrwert, was mich persönlich angeht aber kein dringender Feature-Wunsch...