Post && Get bzw, oder, oder wie
Stefan
- php
Moin,
ich weiß uncleverer Betreff, aber mir fällt nix kurzes ein.
Folgendes, in meinen Scripten prüfe ich per if($_POST['gesendet']=='jaDoch') ob ein Form per Post das Feld(hidden) gesendet mit dem Wert jaDoch enthält. Ich verwende fast ausschließlich Post als Methode. Nun gibt es jedoch für Firebird diverse Erweiterungen. U.a die Web-Developer (ich habe die selber installiert). Dort kann man unter dem Punkt "Forms" die Sendeart von Post auf Get und umgekehrt ändern.
Was soll ich machen? Alle Scripts auf beide Methoden ändern oder mich ruhig hinsetzen und mir sagen "Dann gehts bei dem User halt nicht, wenn er sowas macht"?
Oder gibt es was besseres um sicher zu gehen, daß der User mit den! Werten von da! kam wo ich es erwarte (Sicherheit).
Danke
Ste
hi,
Nun gibt es jedoch für Firebird diverse Erweiterungen. U.a die Web-Developer (ich habe die selber installiert). Dort kann man unter dem Punkt "Forms" die Sendeart von Post auf Get und umgekehrt ändern.
Was soll ich machen?
nichts natürlich.
Alle Scripts auf beide Methoden ändern oder mich ruhig hinsetzen und mir sagen "Dann gehts bei dem User halt nicht, wenn er sowas macht"?
der user, der sowas macht, sollte wissen, was er tut.
und ein vernünftiger mensch wird dieses feature idR. wohl eh nur zum testen einsetzen.
Oder gibt es was besseres um sicher zu gehen, daß der User mit den! Werten von da! kam wo ich es erwarte (Sicherheit).
das kannst du weder bei GET noch bei POST.
du kannst ja nicht mal erwarten, dass er einen _browser_ benutzt hat.
gruss,
wahsaga
Moin wahsaga,
das kannst du weder bei GET noch bei POST.
du kannst ja nicht mal erwarten, dass er einen _browser_ benutzt hat.
ACK bei Get, aber POST(außer evtl. irgendwelche Scripte)?
Ste
Hallo,
in meinen Scripten prüfe ich per if($_POST['gesendet']=='jaDoch') ob ein Form per Post das Feld(hidden) gesendet mit dem Wert jaDoch enthält.
OK, damit akzeptierst Du ausschliesslich die von Dir im
HTML-Formular vorgeschriebene POST-Methode.
Das ist in Ordnung.
Wenn Du es Anfaengern und Fire***-Benutzern leichter
machen willst, Deinem Skript irgendwelche Werte unterzujubeln,
dann darfst Du ruhig auch GET- und Cookie-Parameter akzeptieren,
ohne die Methode zu unterscheiden.
Dafuer waere dann $_REQUEST zustaendig.
Ansonsten lass es so, wie es ist.
Oder gibt es was besseres um sicher zu gehen, daß der User mit den! Werten von da! kam wo ich es erwarte (Sicherheit).
Hidden-Variablen sind ein laecherlicher "Schutz".
Auch method="POST" ist nur ein schwacher Schutz.
Auf den Referrer kannst Du schon gar nicht gehen.
Wenn schon muesstest Du mit Sessions oder aehnlichen
Mechanismen jedem Formular einen eindeutigen
Wert mitgeben (Suchbegriff: "Challenge") und diesen
gleichzeitig auf dem Server speichern.
Das verarbeitende Skript schaut dann nach, ob
der Wert in Ordnung ist. Damit kannst Du gleichzeitig
verhindern, dass ein Benutzer das gleiche Formular
mehrmals abschickt.
Gruesse,
Thomas
Moin,
erstmal danke.
Hidden-Variablen sind ein laecherlicher "Schutz".
Auch method="POST" ist nur ein schwacher Schutz.
Auf den Referrer kannst Du schon gar nicht gehen.
Das ist mir auch klar. Bin nur heute mal wieder drüber gestolpert.
Wenn schon muesstest Du mit Sessions oder aehnlichen
~snipp
gleichzeitig auf dem Server speichern.
Dieser Mechanismus (nicht genau dieser aber ein ähnlicher) ist implementiert(außerdem eine User/PWD-Kombination). Nur ist es halt so, daß, wenn einer mittels FB die Methode ändert eine Fehlerseite erhält.
Ich erweitere mal die Frage um den Punkt:"Ist es Userfriendly zu checken das die Methode falsch war und dem User das mitzuteilen" und lohnt sic der Aufwand (Projekte mehr privat und etwas B2B(um wenig Geld))?
Stefan
Hi,
Ich erweitere mal die Frage um den Punkt:"Ist es Userfriendly zu checken das die Methode falsch war und dem User das mitzuteilen" und lohnt sic der Aufwand (Projekte mehr privat und etwas B2B(um wenig Geld))?
Wer sowas bei fremden Formularen macht, ist IMHO selber schuld.
Das Teil ist ja auch als Web-Developer benannt - ich denke, wer das einsetzt, tut das vor allem, um seine eigenen Seiten zu testen - um zu sehen, was bei falscher Methode geschieht, ohne daß er jedesmal die Seite ändern muß...
cu,
Andreas
Hallo,
Nur ist es halt so, daß, wenn einer mittels FB die Methode ändert eine Fehlerseite erhält.
Dann hat dieser Benutzer bewusst rumgespielt.
Und soll sich nicht wundern, wenn sein Vorhaben in die Hosen geht.
"Ist es Userfriendly zu checken das die Methode falsch war und dem User das mitzuteilen" und lohnt sic der Aufwand (Projekte mehr privat und etwas B2B(um wenig Geld))?
Ich kann mir nicht vorstellen, dass ein heute noch
"funktionierender" Browser die beiden Methoden
POST und GET verwechselt bzw. sich nicht
an die Vorgabe im HTML-Formular haelt.
Immerhin wurden die beiden Methoden schon
in HTML 2.0 (1995) und HTTP/1.0 (1996)
und vermutlich sogar schon frueher (HTTP/0.9)
festgelegt.
Von da her duerften nur Personen, die zuviel Zeit
oder kriminelle Energie haben, Dir das Formular
per GET schicken, obwohl Du method="POST"
vorschreibst.
Verliere nicht Deine Zeit fuer solche Personen.
Achte darauf, dass Du keine Sicherheitsloecher
hast, und gut ist.
Just my 2 cents,
Thomas
Hallo,
eigentlich nicht so schwer
if($wert_aus_deiner_db == "post")
{
//Quellcode mit $_POST Abfrage
}
else
{
//Quellcode mit $_GET Abfrage
}
MFG
Andavos
hi,
if($wert_aus_deiner_db == "post")
{
//Quellcode mit $_POST Abfrage
}
else
{
//Quellcode mit $_GET Abfrage
}
1. von welchem $wert_aus_deiner_db redest du?
2. anstatt hier den code zu doppeln, wäre die benutzung des von Thomas schon erwähnten $_REQUEST wohl deutlich einfacher.
gruss,
wahsaga
Hallo,
Nun gibt es jedoch für Firebird diverse Erweiterungen. U.a die Web-Developer (ich habe die selber installiert). Dort kann man unter dem Punkt "Forms" die Sendeart von Post auf Get und umgekehrt ändern.
Was soll ich machen?
Nichts!
Wenn man im Web-Developer diese Funktion benutzt, wird sie meines Wissens nach auch nur einmalig angewendet. Nach dem Aufruf werden im Quelltext der Seite alle POSTs zu GETs umgewandelt (oder umgekehrt). Bei erneutem Laden ist die Seite aber wieder in ihrem urspruenglichen Zustand. Das bedeutet, man kann diese Funktion nicht "aus Versehen" aktiviert haben und sie wird wohl wirklich nur testweise von Entwicklern angewendet werden.
Und die Omi von nebenan wird sich wohl auch keine Web-Developer-Extensions installieren. :-)
Ausserdem kannst Du nie gegen voellige Fehlbedienung des Users gefeit sein, es sei denn, Du stehst persoenlich neben ihm. So koennte ein User nach dem Ausfuellen Deines Formulars den Webbrowser beenden oder ein anderes Bookmark aufrufen, noch bevor er den Submit-Button gedrueckt hat. In diesem Fall wuerdest Du auch die Formulardaten nicht bekommen. Und da kannst Du auch nichts gegen tun, genauso wie in dem von Dir geschilderten Fall.
Grüße, Alex.