Guten Tag Jens,
das ist ein typischer Fall für eine Vorgangsbearbeitung und Sessions, bzw. den Einsatz von Cookies.
Wenn Du ein Script hast, das nur von authorisierten Nutzern verwendet werden darf, dann musst Du trotz Authorisierung noch prüfen, ob es auch JETZT verwendet werden darf, und ob die zur Verfügung gestellten Daten auch authentisch sind. Auch ein zugelassener User kann Dir alles zurückschicken...
Mal ein praktisches Beispiel:
über eine Auswahlliste kannst Du Datensätze zum Markieren und Löschen bereitstellen. Wie schickst Du die Information, welche Sätze gelöscht werden sollen zurück an den Server? Du wirst wohl ein Feld mit Typ Array und z.B. den IDs der zu löschenden Records an den Server posten. Nun musst Du am Server prüfen, ob die gesendeten IDs überhaupt von dem User benutzt/gesehen/gelöscht werden dürfen.
Einfacher ist es, das bereits bei der Abfrage zu tun und es in der Session zu speichern. Wenn jetzt IDs zurückgepostet werden, dann muss keine erneute SQL-Abfrage (vielleicht über viele viele Stufen) durchgeführt werden, sondern nur in den im Vorgang gespeicherten IDs nachgeschaut werden, ob die geposteten da drin stehen. Wenn auch nur eine dabei sit, die nicht dazu gehört, dann wird sofort der gesamte Vorgang wegen Fake abgebrochen.
Noch besser ist es, jedem Vorgang eine eigene PIN zu geben, unter der das Array mit allen Vergleichsdaten in der Session abgelegt wird. Diese PIN sendet man dann z.B. als Hidden-Field mit dem Formular an den Client. Wenn der User dann eine falsche postet, wird die logische Verbindung gleich abgebrochen.
Grüße
Tom