nicht angemeldet einsiedler
Rolf B
localhorst
localhorst
Rolf B
localhorst
Rolf B
einsiedler
Rolf B
localhorst
localhorst
Hallo liebe Forumer,
ich suche eine Möglichkeit in meinem .htaccess HEAD und POST requests zu unterbinden:
Was ist hiervon richtig?
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_METHOD} ^(head|post) [NC]
RewriteRule .* - [F]
</IfModule>
oder:
<Limit GET HEAD OPTIONS POST PUT>
Order Allow,Deny
Deny from All
</Limit>
Und was sollte ich noch "sperren"?
Gruß der einsiedelnde
Hallo einsiedler,
ich suche eine Möglichkeit in meinem .htaccess HEAD und POST requests zu unterbinden
Ich bin viellecht dumm und naiv, aber wo ist der Zweck? HEAD könnte ich noch verstehen, aber HEAD-Requests schaden eigentlich keinem.
HEAD dient dazu, so zu tun als wär's ein GET, liefert aber nur die Header ohne den Content. Einen HEAD Request auf PHP musst Du im Script behandeln, damit er wie gewünscht stattfindet. Einen HEAD-Request auf andere Ressourcen kann man, wenn Du HEAD abweist, jederzeit durch GET ersetzen. Wenn sich der Client nur für die Header interessiert, liest er nur die ersten Lines, bis zum Content, und bricht den Empfang dann ab. Unterm Strich belastet das nur deinen Server höher.
Einen POST auf HTML-Dateien wird der Server ohnehin ignorieren. Ein POST auf PHP bewirkt nur was, wenn deine Seiten das auch interpretieren und behandeln, andernfalls wirkt der POST wie ein GET.
Und wenn Du POST globalgalaktisch abklemmst, dann funktioniert das hier auch nicht mehr.
<form action="login.php" method="post">
...
</form>
Du müsstest einen GET-Request daraus machen. Und dann steht das Passwort klar lesbar in deinem Brauserverlauf.
Rolf
Hallo Rolf,
hallo Alle,
HEAD dient dazu, so zu tun als wär's ein GET, liefert aber nur die Header ohne den Content. Einen HEAD Request auf PHP musst Du im Script behandeln, damit er wie gewünscht stattfindet.
Kommt ein HEAD-Request überhaupt im Skript an? Wird der nicht üblicherweise direkt vom Webserver beantwortet? Es geht doch nur um das Vorhandensein und die Zugänglichkeit der Ressource.
LG + Gesundheit
Localhorst
Hallo Alle,
HEAD dient dazu, so zu tun als wär's ein GET, liefert aber nur die Header ohne den Content. Einen HEAD Request auf PHP musst Du im Script behandeln, damit er wie gewünscht stattfindet.
Kommt ein HEAD-Request überhaupt im Skript an? Wird der nicht üblicherweise direkt vom Webserver beantwortet? Es geht doch nur um das Vorhandensein und die Zugänglichkeit der Ressource.
Ok! dringende Korrektur
siehe hierzu den Thread zum Thema Sicherheit
LG + Gesundheit
Localhorst
Hallo localhorst,
doch, kommt er. Gerade ausprobiert - mangels eines besseren Tools mit TELNET und manuell eingetippten HTTP Befehlen. Aua aua, der Zwang zu NULL Tippfehlern macht keinen Spaß.
Es ist jedenfalls so, dass das Script gestartet wird. Das erkenne ich daran, dass ein HTTP Header zurückkam, den ich im Script gesetzt habe. Der Content des Scripts wird aber unterdrückt.
Heißt: HEAD Requeste gegen ein PHP Script sind eine nette Methode, um den Server zu beschäftigen, ohne sich mit dem Transfer der Antwortdaten aufzuhalten. Im IIS kann ich aber die Verben festlegen, die für eine bestimmte Handlerzuordnung beachtet werden sollen. Da stand vorher "Alles", jetzt noch "GET, POST" und prompt bekomme ich HTTP 404 zurück.
Nachtrag: die erste Benutzerausgabe bricht das Script ab, wie ich im Posting von localhorst gelernt habe, d.h. kritisch sind nur Scripte die strikt an EVA glauben und fleißig rumrödeln, bevor sie die erste Ausgabe machen.
Aber, es ist nicht immer sinnvoll, die Verben im Server zu blocken. Würde ich nun REST Service auf dieser Adresse bauen wollen, ginge das nicht, der braucht ja das volle Verbenspektrum.
Rolf
Hallo Rolf,
hallo Alle,
ja, ja.
Die anfänglich dümmsten Fragen (weil man ja selber sowieso alles besser weiß :-) ) führen rückwirkend betrachtet doch oft noch zu (erheblichem) Erkenntnisgewinn. Ich musste meine selbst gestellte Frage nach dem Durchschlagen eines HEAD-Request auf das Skript dann ja auch mit Erstaunen beantworten...
Aber dein Satz mit dem Rumrödeln lässt mich jetzt das voreingestellte PHP-Verhalten zu den Output-Buffers in Verbindung mit Apache nochmal überprüfen. Da ist nämlich seit PHP Ver5.3ff (?) immer mindestens eine OB-Shell aktiv. Wenn man zeitnahe Responses wünscht, musste man zuerst (in einer Schleife oder rekursiv) alle OBs abschalten.
Das ist imho nirgends offiziell dokumentiert. Allerdings gab es hier schon etliche Threads zu dem Thema.
LG + Gesundheit
Localhorst
Hallo localhorst,
wenn das denn reicht. Hier steht, dass auch mod_deflate noch reingrätschen kann und output verhindertzögert.
TL;DR: Frage das Verb ab.
Rolf
ich suche eine Möglichkeit in meinem .htaccess HEAD und POST requests zu unterbinden
sudo systemctl stop apache2
wäre wohl die sinnvollste Möglichkeit, dieses zu tun. Verrate doch mal, was Du warum erreichen willst. Wie Du bei Rolf schon nachlesen kannst, erscheint Dein Vorhaben „ziellos“ und wird später geradezu zwangsweise zu Problemen führen - weshalb zielführende Antworten nur schwer möglich sind.
<Limit GET HEAD OPTIONS POST PUT> Order Allow,Deny Deny from All </Limit>
Wenn es um Zugriffsbeschränkungen geht, sollte ein <LimitExcept>-Container sollte immer einem <Limit>-Container vorgezogen werden, da <LimitExcept> einen Schutz gegen beliebige Methoden bietet.
Vielleicht willst Du wenigstens GET, HEAD und POST erlauben und auf die modernen Schreibweisen umstellen, die kein Kompatiblitätsmodul für alte Apache-Versionen erfordern:
<LimitExcept GET HEAD POST>
Require 127.0.0.1
</LimitExcept>
Grund Openssl (für HTTPS) braucht offenbar Options und wenn ein Angriff vonm localhost kommt hast Du eh schon andere Probleme...:
127.0.0.1 - - [01/Mar/2021:19:29:24 +0000] "OPTIONS * HTTP/1.0" 200 117 "-" "Apache/2.4.38 (Raspbian) OpenSSL/1.1.1i (internal dummy connection)"
Hallo Raketenkonfiguarationsbeschreiber,
hallo Alle,
<Limit GET HEAD OPTIONS POST PUT> Order Allow,Deny Deny from All </Limit>Wenn es um Zugriffsbeschränkungen geht, sollte ein <LimitExcept>-Container sollte immer einem <Limit>-Container vorgezogen werden, da <LimitExcept> einen Schutz gegen beliebige Methoden bietet.
Vielleicht willst Du wenigstens GET, HEAD und POST erlauben und auf die modernen Schreibweisen umstellen, die kein Kompatiblitätsmodul für alte Apache-Versionen erfordern:
<LimitExcept GET HEAD POST> Require 127.0.0.1 </LimitExcept>
<LimitExcept HEAD GET POST>
Require IP 127 ::1
</LimitExcept>
Siehe LimitExcept
Vergiss ::1 für ipv6 nicht. Sonst sind eventuell doch keine lokalen Zugriffe mehr möglich.
LG + Gesundheit
Localhorst
Nunja, da sind irgendwelche Spacken die es auf mich aubgesehen haben:
Hier ein Paar Logs:
"POST"
2021-02-27 07:23:13 Error 52.188.55.90 404 GET /.env HTTP/1.0 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36 1.21 K Apache-Zugriff
2021-02-27 07:23:14 Error 52.188.55.90 403 POST / HTTP/1.0 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36 5.21 K Apache-Zugriff
2021-02-28 15:58:17 Error 188.34.158.15 403 GET / HTTP/1.0 page-preview-tool Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36 5.21 K Apache-Zugriff
2021-02-28 15:58:17 Error 188.34.158.15 AH01797: client denied by server configuration: /var/www/vhosts/xxx.de/httpdocs_xxx/ Apache-Fehler
2021-02-28 16:07:00 Error 139.162.52.129 403 GET /.env HTTP/1.0 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36 1.20 K Apache-Zugriff
2021-02-28 16:07:00 Error 139.162.52.129 AH01797: client denied by server configuration: /var/www/vhosts/xxx.de/httpdocs_xxx/.env Apache-Fehler
2021-02-28 16:07:01 Error 139.162.52.129 403 GET /vendor/.env HTTP/1.0 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36 1.20 K Apache-Zugriff
2021-02-28 16:07:01 Error 139.162.52.129 AH01797: client denied by server configuration: /var/www/vhosts/xxx.de/httpdocs_xxx/vendor/.env Apache-Fehler
2021-02-28 16:07:02 Error 139.162.52.129 403 GET /storage/.env HTTP/1.0 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36 1.20 K Apache-Zugriff
2021-02-28 16:07:02 Error 139.162.52.129 AH01797: client denied by server configuration: /var/www/vhosts/xxx.de/httpdocs_xxx/storage Apache-Fehler
2021-02-28 16:07:03 Error 139.162.52.129 403 GET /public/.env HTTP/1.0 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36 1.20 K Apache-Zugriff
2021-02-28 16:07:03 Error 139.162.52.129 AH01797: client denied by server configuration: /var/www/vhosts/xxx.de/httpdocs_xxx/public Apache-Fehler
2021-02-28 16:07:04 Error 139.162.52.129 403 POST / HTTP/1.0 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36 5.21 K Apache-Zugriff
2021-02-28 16:07:04 Error 139.162.52.129 AH01797: client denied by server configuration: /var/www/vhosts/xxx.de/httpdocs_xxx/ Apache-Fehler
2021-02-28 17:11:13 Access 54.202.113.170 302 GET / HTTP/1.0 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36 1.23 K Apache-Zugriff
2021-02-28 18:40:06 Error 139.162.182.111 404 GET /checkout HTTP/1.0 Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0 1.21 K Apache-Zugriff
2021-02-27 00:12:01 Error 139.162.52.129 404 GET /.env HTTP/1.0 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36 1.21 K Apache-Zugriff
2021-02-27 00:12:02 Error 139.162.52.129 404 GET /vendor/.env HTTP/1.0 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36 1.21 K Apache-Zugriff
2021-02-27 00:12:03 Error 139.162.52.129 404 GET /storage/.env HTTP/1.0 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36 1.21 K Apache-Zugriff
2021-02-27 00:12:04 Error 139.162.52.129 404 GET /public/.env HTTP/1.0 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36 1.21 K Apache-Zugriff
2021-02-27 00:12:05 Error 139.162.52.129 403 POST / HTTP/1.0 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36 5.21 K Apache-Zugriff
2021-02-27 05:50:50 Error 52.188.55.90 404 GET /.env HTTP/1.0 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36 1.21 K Apache-Zugriff
2021-02-27 05:50:50 Error 52.188.55.90 403 POST / HTTP/1.0 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36 5.21 K Apache-Zugriff
2021-02-27 07:29:04 Error 5.188.62.76 403 GET / HTTP/1.0 Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36 5.21 K Apache-Zugriff
2021-02-27 07:29:04 Error 5.188.62.76 AH01797: client denied by server configuration: /var/www/vhosts/xxx.de/xxx.de/ Apache-Fehler
"HEAD"
2021-02-27 00:40:58 Access 138.246.253.24 301 HEAD / HTTP/1.1 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.146 Safari/537.36 0 SSL/TLS-Zugriff für Apache
2021-02-27 00:45:35 Access 35.230.69.215 301 HEAD / HTTP/2.0 https://t.co/pUAeOb5lBy Unbekannt 0 SSL/TLS-Zugriff für Apache
2021-02-27 00:45:36 Error 35.230.69.215 400 HEAD / HTTP/1.0 https://www.xxx.de/ Unbekannt 137 Apache-Zugriff
usw. und so fort...
Jeden tag habe ich soetwas.
Bisher setze ich auf den beiden Seiten wo ich ein Login habe das hier ein:
# whitelist POST requests
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} !/login.php [NC]
RewriteCond %{REQUEST_URI} !/register.php [NC]
RewriteCond %{REQUEST_URI} !/forgotten.php [NC]
RewriteCond %{REQUEST_URI} !/verify.php [NC]
RewriteCond %{REQUEST_URI} !/reset.php [NC]
RewriteCond %{REMOTE_ADDR} !127.0.0.1
RewriteRule .* - [F,L]
</IfModule>
Um ein "Registrieren" und ein "Login" überhaupt noch zu ermöglichen und nicht so ein "wildes POST" zu bekommen welches keinen Sinn macht.
Also was müsste ich da nun tun? Ist das was ich bisher habe korrekt so? Wie erweitere ich es auch für "HEAD"?
Gruß der einsiedelnde
Hallo einsiedler,
„Spacken“ ist ein Begriff, der meiner Kenntnis nach von "Spastiker" abgeleitet ist. Der Begriff ist sehr unsensibel, ihn als Beleidigung zu verwenden beleidigt vor allem diejenigen, die an spastischen Lähmungen erkrankt sind. Bitte vermeide diesen Begriff.
Die Leute, die Dich da abgrasen, sind hinter der ganzen Welt her, man nennt sie die Script-Kiddies. Sie suchen einfach sämtliche IPs dieser Welt ab und suchen nach Verwundbarkeiten. Das ist nichts persönliches. Als Webseitenbetreiber muss man da drüber stehen.
Eine .env Datei gibt's bei Docker, oder dem Vernehmen nach auch bei npm. Da können Konfigurationsdaten zum Server drin stehen und damit weitere Angriffe ermöglichen. Ein anständig eingerichteter Server lässt "Punkt"-Dateien aber nicht an die frische Luft. Ordner wie vendor, storage und public finden sich in diversen Frameworks, um Zusatzbibliotheken abzulegen. Offenbar findet sich dort auch gelegentlich mal eine verräterische .env Datei.
Mit einer Blockade von HEAD oder POST Requests bringst Du die Kiddies aber auch nicht zur Ruhe. Sie kommen dann irgendwann mit dem nächsten Rechen vorbei und kämmen Dich nach was anderem durch.
Rolf
Also was müsste ich da nun tun?
Dich auch mal zurück lehnen. Was Du zeigst ist wie Regen, der gegen das Fenster trommelt.
Hallo einsiedler,
hallo Alle,
der Wunsch, nur erlaubte Requests zuzulassen, ist nachvollziehbar.
Allerdings sind Head-, Get- und Postrequests in einem Dialogsystem zunächst nichts Böses, sie sind sogar erforderlich, um die gestellte Aufgabe zu lösen.
Wenn allerdings Postrequests nur erlaubt sind, wenn der Client autorisiert ist, dann solltest Du nicht authentifizierte Clients, nicht autorisierte Posts (also solche ohne gültiges "Login") im Skript mit einem passenden Responsecode beantworten. Hier käme 403 (forbidden) oder 406 (not acceptable) in Frage. Hingegen wäre 401 (unauthorized) in einem System, dass mit Token ("Sessioncookie") arbeitet, kontraproduktiv, denn das würde dem Client suggerieren, dass er es mit Benutzername und Passwort noch (mehrmals) über Basic Authentication versuchen soll.
Die .htaccess-Dateien sind bei Token-Athentifizierung ("Session-Cookie") der falsche Weg. Die eignen sich eventuell bei Basic Auth.
Wenn Du nun den passenden Responsecode gesendet hast (ggf. mit eigenem Responsebody), dann sollte der im Log auftauchen.
Das Log kannst Du nun mit Überwachungssoftware beobachten, z.B. fail2ban. Wenn dort für HTTP/S-Zugriffe eine passende Regel hinterlegt ist, könnten unerwünschte Posts von derselben IP z.B. nach 10 Fehlversuchen für eine (kurze) Zeit geblockt werden. Durch ein weiteres Filter für fail2ban kann man außerdem noch eine weitere, längere Sperre (auch für sehr lange Zeit) einleiten lassen, wenn die kurze Sperrung innerhalb eines bestimmten Intervalls öfter zugeschlagen hat. Darüber kann man sich auch per E-Mail benachrichtigen lassen und dann permanente Maßnahmen vornehmen.
Das funktioniert, einmal vernünftig eingerichtet, über Jahre automatisch.
LG + Gesundheit
Localhorst
Hallo einsiedler,
hallo Alle,
da mich die Frage mit dem HEAD-Request auf PHP-Ressourcen durchaus tiefer interessiert, habe ich noch ein wenig tiefer recherchiert, und bin auf diesen Thread in phpgansta.de gestoßen.
Eine durchaus lesenswerte Variante, warum Spammer/Netzkriminelle HEAD-Requests absetzen könnten.
♡♡♡ ♡♡♡ ♡♡♡ ♡♡♡
Hinweis:
Meine Antworten beziehen sich (meistens) auf den gesamten bisherigen Thread. Der/die jeweilige direkte Vorposter/in sollte sich daher nicht alleine angesprochen fühlen.
♡♡♡ ♡♡♡ ♡♡♡ ♡♡♡
LG + Gesundheit
Localhorst
Hallo localhorst,
oh, wow, soweit hatte ich nicht getestet. Es ist aber auch dämlich programmiert, zuerst den Admin-Mode in der Session einzuschalten und erst dann die Berechtigung zu prüfen.
Wir lernen daraus: Wenn Du die Verben nicht auf Serverebene filtern kannst oder willst, dann frage das Verb ab ($_SERVER['REQUEST_METHOD']), bevor Du etwas tust!
Rolf
Tach!
da mich die Frage mit dem HEAD-Request auf PHP-Ressourcen durchaus tiefer interessiert, habe ich noch ein wenig tiefer recherchiert, und bin auf diesen Thread in phpgansta.de gestoßen.
Da ist man als Programmierer selbst schuld. HEAD-Requests sind wie GET. Wer bei GET serverseitige Daten verändert, hat sowieso ein Problem. Das macht ein HEAD-Request dann auch nicht mehr schlimmer.
Zudem kann jedes Script auch durch andere Ursachen abgebrochen werden. Wer (bei POST) kritische Dinge macht, und diese nicht in einer Transaktion absichert, hat nicht unbedingt Mitleid verdient.
dedlfix.
Hallo dedlfix,
hallo Alle,
da mich die Frage mit dem HEAD-Request auf PHP-Ressourcen durchaus tiefer interessiert, habe ich noch ein wenig tiefer recherchiert, und bin auf diesen Thread in phpgansta.de gestoßen.
Da ist man als Programmierer selbst schuld. HEAD-Requests sind wie GET. Wer bei GET serverseitige Daten verändert, hat sowieso ein Problem. Das macht ein HEAD-Request dann auch nicht mehr schlimmer.
Zudem kann jedes Script auch durch andere Ursachen abgebrochen werden. Wer (bei POST) kritische Dinge macht, und diese nicht in einer Transaktion absichert, hat nicht unbedingt Mitleid verdient.
Bitte nimm es nicht übel, aber mich stört immer diese "Hülsensprache". Könntest Du deine Aussagen etwas konkretisieren, ggf. mit Beispielen?
Bei HEAD vs. GET kann ich noch mithalten. Mit beiden sollten keine datenverändernden Abfragen durchgeführt werden. Spannend bleibt da die Grenzziehung bei den Sessiondaten, wie das zugegeben konstruierte Beispiel von phpgangsta zeigt.
Wie man bereits in der PHP-Schicht kaputte Daten verhindern kann, das wird hier noch nicht klar.
Es gibt dafür die Funktionen rund um ignore_user_abort(), die man ab einem gewissen Fortschritt in der Logik eines Controllers immer benutzen sollte - auf jeden Fall vor dem Auslösen eines DMS (Data Modification Statement) an der Datenhaltung.
Eine Transaktion ist imho nur für den Kern des DMS selber verantwortlich, nicht aber für seine vollständige Ausführung. Wird bei Skriptabbruch mitten in einer komplexen Transaktion das Rollback trotzdem durchgeführt, oder fällt das unter den Tisch?
Imho entstehen viele Inkonsistenzen an Web-Datenbeständen gerade an dieser Stelle.
Es bleibt also die Frage offen, wie sauber die Transaktion gekapselt ist und damit unabhängig vom vorzeitigen Abbruch des Skriptes ist.
Und wie gestaltet man eine vollständig gekapselte Transaktion, wenn gar kein gesonderter Datenbankserver im Spiel ist (SQLite, o.ä.)?
LG + Gesundheit
Localhorst
Tach!
Bitte nimm es nicht übel, aber mich stört immer diese "Hülsensprache". Könntest Du deine Aussagen etwas konkretisieren, ggf. mit Beispielen?
Wenn du mir sagst, wo die Verständnisprobleme liegen, kann ich nachzulegen versuchen.
Bei HEAD vs. GET kann ich noch mithalten. Mit beiden sollten keine datenverändernden Abfragen durchgeführt werden. Spannend bleibt da die Grenzziehung bei den Sessiondaten, wie das zugegeben konstruierte Beispiel von phpgangsta zeigt.
Ja, man kann es ohne Not andersherum schreiben, so dass die Berechtigung erst bei erfolgreicher Autorisierung vergeben wird. Deswegen stufe ich das Beispiel als nicht weiter relevant ein.
Wie man bereits in der PHP-Schicht kaputte Daten verhindern kann, das wird hier noch nicht klar.
Keine Daten im GET zu ändern löst das Problem. Anmeldungen erfolgen mit POST. Berechtigungsrelevante Session-Daten schreibt man also auch damit.
Eine Transaktion ist imho nur für den Kern des DMS selber verantwortlich, nicht aber für seine vollständige Ausführung.
Ja, wenn man sich dabei auf Datenbanktransaktionen beschränkt.
Schreibt man selbst Dateien, und hat einen solchen Anspruch, muss man etwas ähnliches entwerfen. Wird sicher nicht ganz einfach in einer konkurrierenden Multiuser-Umgebung.
Wird bei Skriptabbruch mitten im einer komplexen Transaktion das Rollback trotzdem durchgeführt, oder fällt das unter den Tisch?
Beschränkt auf Datenbank-Transaktionen: Die Änderungen erfolgen meines Wissens nicht direkt im Datenbestand. Wenn die Client-Session ohne Commit beendet wird, auch bei Timeout, dann werden die Änderungen verworfen und nicht in die Tabellen eingetragen. Der Rollback wird bei Abbruch also implizit ausgeführt.
Es bleibt also die Frage offen, wie sauber die Transaktion gekapselt ist und damit unabhängig vom vorzeitigen Abbruch des Skriptes ist.
Bezogen auf einen selbst erstellten Transaktionsmechanismus: Ja, aber das ist ein anderes Thema.
dedlfix.