ist die antwort von rwx vom 9.6.2005 auf eine ähnliche anfrage:
zitat rwx:
wir stellen uns jetzt mal ganz dumm:
1. user schreibt einen beitrag und klickt auf abschicken
2. der browser schickt einen request an den server in dem steht, trag doch bitte mal den beitrag ein
3. der server kriegt den request trägt den beitrag ein und zeigt ihn dann direkt auch an
4. der user klickt reload
5. der browser schickt den gleichen request wieder
6. der server trägt den für ihn neuen beitrag ein
von der technischen seite ganz logisch. es gäbe schon möglichkeiten das abzustellen, z.b. so:
1. der user klickt auf beitrag schreiben und kommt auf die seite mit dem eingabe-fenster, in diese seite hat der server eine zufallszahl integriert
2. schickt der user jetzt den beitrag zum server muss die zufallszahl stimmen, sonst wird der beitrag nicht angenommen.
dann wäre das reload-problem weg, dafür neue probleme da:
1. der server muss sich die ganzen zahlen erstmal merken und einem user und forum zuordnen (könnte ja sein, dass ein user parallel beiträge in verschiedenen foren verfasst)
2. die zahlen können nicht ewig auf dem server bleiben, müssen also irgendwann einen timeout kriegen, d.h. wenn der user zulange warte wird sein beitrag nicht angenommen (so wie das jetzt mit dem session timeout passiert)
3. die zufallszahlen dürfen nicht kollidieren
den aufwand ist mir das nicht wert, da gibts wichtigere sachen auf 4t, außerdem ist die seite schon langsam genug, da muss sie durch sowas nicht noch langsamer werden
