$_POST "resetten"??
0 0 0 
Dennis
0
0
$_POST "resetten"??
Шалом , друзі!
Ich werde mich bemühen die Frage prezise zu fromulieren :)
Frage: wen ich Daten mit einem Formular mittels POST übergebe , ist es leider so , daß (je nach Browsereinstellung) durch das Neuladen der Seite die Daten erneut gesendet werden , hier:
http://bleicher.bl.funpic.de/?mode=komm&num=0003 ist das Problem , daß man durch simples "F5en" immer wieder einen neuen Kommentar erzeugt.Ist es möglich die POSTDaten zu löschen bzw. eine POSTvariable "undefinieren"?Falls nicht - wie geht man üblicherweise damit um??
Danke im Voraus^^
-
Hallo!
Frage: wen ich Daten mit einem Formular mittels POST übergebe , ist es leider so , daß (je nach Browsereinstellung) durch das Neuladen der Seite die Daten erneut gesendet werden , hier:
http://bleicher.bl.funpic.de/?mode=komm&num=0003 ist das Problem , daß man durch simples "F5en" immer wieder einen neuen Kommentar erzeugt.Ist es möglich die POSTDaten zu löschen bzw. eine POSTvariable "undefinieren"?Falls nicht - wie geht man üblicherweise damit um??Den Post verarbeiten und dann mit header("Location: ...") weiterleiten. Der Benutzer bekommt davon nichts mit und kann F5 drücken sooft er will.
mfg
frafu-
Also den insertscript in eine externe datei?? oky^^ danke schön^^
-
Hi bleichr,
Also den insertscript in eine externe datei??
Davon war keine Rede - das Script welches den Kommentar speichert kann per Location ruhig auf sich selber weiterleiten, das geht IHMO auch problemlos.
MfG, Dennis.
--
Mein SelfCode: ie:{ fl:( br:> va:) ls:[ fo:) rl:( n4:# ss:) de:] js:| ch:{ sh:| mo:} zu:|
Patch zur Verwendung von PATHINFO in JLog
Unbrauchbarkeit hat noch nie Menschen von der Nutzung abgehalten - Millionen IE-Nutzer beweisen das. >;-> (Cybaer)
-
-
Hallo,
Den Post verarbeiten und dann mit header("Location: ...") weiterleiten. Der Benutzer bekommt davon nichts mit und kann F5 drücken sooft er will.
Das hilft aber nur begrenzt - und zwar im Reload-Fall. Wenn jemand 2x auf "Abschicken" klickt, nützt auch das nichts.
Viele Grüße,
Christian--
"I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." - Bjarne Stroustrup-
wie (ud ob) kann man es verhindern?
wären cookies die den posting verbieten ne lösung??aber die user die keine cookies akzeptieren köntnen es tritzdem machen.. IP-verbot als option??oder deaktivieren der "submit" taste nach dem klcik als einfachste lösung?-
Hallo,
wären cookies die den posting verbieten ne lösung??aber die user die keine cookies akzeptieren köntnen es tritzdem machen.. IP-verbot als option??oder deaktivieren der "submit" taste nach dem klcik als einfachste lösung?
Hier im Forum wird folgendes Schema verwendet: In jedem Formular ist ein Hidden-Feld mit dem Namen "unid" und einem zufälligen Inhalt drin. z.B. so eins:
<input type="hidden" name="unid" value="6zx67Y0xz0zOQ364zBoPHNGh" />Diese Unids werden dann serverseitig mit den Postings gespeichert. Wenn jemand nun ein Posting abschickt, wird kontrolliert, ob die gleiche unid (Du kannst das Feld übrigens gerne auch anders nennen ;-)) schonmal vorhanden ist - wenn ja, dann wird eine Fehlerseite angezeigt, wenn nein, wird das Posting normal verarbeitet.
Die Lösung basiert natürlich darauf, dass der User das nicht mutwillig hintergeht - immer wenn der Nutzer das Formular nochmal angezeigt bekommt, wenn er die Formularseite selbst aufruft, kann ein Script immer neue Requests senden - dagegen kann man schlichtweg nichts machen (außer evtl. die Häufigkeit der Formularbenutzung / IP-Adresse und Zeitraum einschränken). Und wenn das Formular nicht nochmal angezeigt würde, nachdem es abgeschickt wurde, kann das die Verarbeitungslogik auch abfangen, dann wäre der Schutz unnötig. Aber gegen normale User, die nichts böses im Schilde führen, sondern sich nur verklicken o.ä. ist die Lösung sehr gut geeignet.
Achja: Oftmals kann doppeltes Abschicken auch von der eigentlichen Programmlogik abgefangen werden. Stelle Dir z.B. vor, Du hast einen webbasierten Terminkalender und jemand will zweimal an die gleiche Stelle einen Termin eintragen - dann kannst Du ja nachfragen, ob er das wirklich will (zwei Termine auf einmal), oder nicht (es hinge jetzt natürlich vom Konzept ab, ob man sowas grundsätzlich zulassen würde, oder komplett verbieten würde, dann müsste die Nachfrage, wohin der Termin stattdessen gelegt werden solle, sowieso hin).
Viele Grüße,
Christian--
"I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." - Bjarne Stroustrup-
hi,
Die Lösung basiert natürlich darauf, dass der User das nicht mutwillig hintergeht - immer wenn der Nutzer das Formular nochmal angezeigt bekommt, wenn er die Formularseite selbst aufruft, kann ein Script immer neue Requests senden - dagegen kann man schlichtweg nichts machen
Man könnte keine "zufälligen" IDs verwenden, sondern nach einem bestimmten Algorithmus "berechnete".
Allerdings sollte dieser Algorithmus dann natürlich "gut genug" sein, so dass er die Menge solcher IDs nicht zu sehr einschränkt.gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }-
Hallo!
Man könnte keine "zufälligen" IDs verwenden, sondern nach einem bestimmten Algorithmus "berechnete".
Allerdings sollte dieser Algorithmus dann natürlich "gut genug" sein, so dass er die Menge solcher IDs nicht zu sehr einschränkt.Da würden sich vielleicht GUIDs anbieten.
Ich hab sowas noch nie erzeugt. Desswegen weiß ich nicht wie performant das ist.mfg
frafu-
hi,
Man könnte keine "zufälligen" IDs verwenden, sondern nach einem bestimmten Algorithmus "berechnete".
Allerdings sollte dieser Algorithmus dann natürlich "gut genug" sein, so dass er die Menge solcher IDs nicht zu sehr einschränkt.Da würden sich vielleicht GUIDs anbieten.
Nein, ich denke eher nicht.
Diese GUIDs _sind_ reichlich zufällig.
Mein Vorschlag basiert aber darauf, dass der Server die "Gültigkeit" einer ID prüfen kann - stelle es dir wie die Seriennummer einer Software vor. Und das sehe ich bei GUIDs nicht gegeben.gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }
-
-
-
-
-
-
-
Moin!
Frage: wen ich Daten mit einem Formular mittels POST übergebe , ist es leider so , daß (je nach Browsereinstellung) durch das Neuladen der Seite die Daten erneut gesendet werden
Falsch! Es hängt NICHT von den Browsereinstellungen ab, es wird IMMER neu gesendet.
Und das ist logisch: Wenn du ein GET-Formular abschickst, kriegst du eine URL der Form http://www.example.org/seite.ext?irgend=welche&werte=hier.
Wenn du diese URL neu lädst - was erwartest du? Das aufgerufene Skript wird diese Parameter erneut entgegennehmen und verarbeiten und entsprechend reagieren. Lade einfach mal die Suchergebnisseite bei Google neu: Da kriegst du auch wieder neue Suchergebnisse.
Bei POST ist das absolut gleich - nur dass du die Daten nicht in der URL siehst.
Ansonsten: Dein Thema ist schon so häufig behandelt worden, dass man es eigentlich kaum verfehlen kann, wenn man hier im Forum mitliest, oder das Archiv befragt.
- Sven Rautenberg
--
"Love your nation - respect the others."-
en der Seite die Daten erneut gesendet werden
Falsch! Es hängt NICHT von den Browsereinstellungen ab, es wird IMMER neu gesendet.
Hi! Opera hat mich mal gefragt " um diese Seite zu aktualisieren müssen postdaten neugesendet werden ja/nein" o s.ä. ich habe leider "ja + warnung nicht mehr anzeigen" gewählt ;D aber daß es bei den meisten standarteinstellung ist glaube ich ja^^
-