Übler IE8 Bug?
0 0 
Felix Riesterer
0 0 Felix Riesterer
0
0
Übler IE8 Bug?
Hallo,
ich hab eine php-Applikation, bei der ich einem Nutzer virtuelles Geld gutschreiben kann. Neuerdings wurde das Geld immer doppelt gutgeschrieben und das, obwohl ich Mechanismen eingebaut habe, die es über die Session verhindern, daß ein method-post-Formular zweimal abgeschickt werden kann.
Jetzt habe ich in den Apache-Logs gesehen, daß dieses Formular zweimal parallel vom IE8 abgeschickt wird und php noch nicht die Zeit hatte, um nach Abarbeiten des Formulars den Schutz für erneutes Absenden zu setzen.
Die Posts sind immer doppelt, allerdings nur mit dem IE8(Final):
127.0.0.1 - - [31/Mar/2009:14:57:25 +0200] "POST /foo.php HTTP/1.1" 200 7743
127.0.0.1 - - [31/Mar/2009:14:57:25 +0200] "POST /foo.php HTTP/1.1" 200 7743
Ist dieser Bug bekannt?
VG,
root66
-
Yerf!
Die Posts sind immer doppelt, allerdings nur mit dem IE8(Final):
127.0.0.1 - - [31/Mar/2009:14:57:25 +0200] "POST /foo.php HTTP/1.1" 200 7743
127.0.0.1 - - [31/Mar/2009:14:57:25 +0200] "POST /foo.php HTTP/1.1" 200 7743Ist dieser Bug bekannt?
Wirklich die Final vom IE8? In den Betas muss wohl so ein Double-Post-Bug gewesen sein, der sollte aber angeblich behoben sein... (die Info stammt aus dem IE-Blog)
Grundsätzlich Abhilfe schafft wohl nur ein Locking-Mechanismus, der schnell genug greift und 2 parallele Zugriffe auf die Session verhindert (sollte PHP swas nicht automatisch machen?) Ansonsten kann man das jederzeit "händisch" provozieren um dein System auszuhebeln.
Gruß,
Harlequin
--
<!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->-
Lieber Harlequin,
Grundsätzlich Abhilfe schafft wohl nur ein Locking-Mechanismus
richtig!!
(sollte PHP swas nicht automatisch machen?)
Auf garkeinen Fall!!
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)-
Yerf!
» (sollte PHP swas nicht automatisch machen?)
Auf garkeinen Fall!!
PHP soll nicht sicherstellen, das 2 Scripte parallel auf der selben Session arbeiten und sich diese gegenseitig zerschreiben?
Hm, ok... vielleicht überseh ich auch nur ein Detail.
Gruß,
Harlequin
--
<!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->-
Lieber Harlequin,
Hm, ok... vielleicht überseh ich auch nur ein Detail.
das Detail heißt "automatisch". Ein Locking-Mechanismus ist zwingende Pflicht bei sowas! Und es muss vom Script-Autor geleistet werden, keinesfalls von PHP selbst. Das fördert auf der einen Seite unzuverlässige Scripte (weil Autoren nachlässig werden -> register_globals) und kann auf der anderen Seite im Ernstfall versagen, da PHP die exakte Scriptarchitektur nicht versteht!
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)-
Yerf!
das Detail heißt "automatisch". Ein Locking-Mechanismus ist zwingende Pflicht bei sowas! Und es muss vom Script-Autor geleistet werden, keinesfalls von PHP selbst. Das fördert auf der einen Seite unzuverlässige Scripte (weil Autoren nachlässig werden -> register_globals) und kann auf der anderen Seite im Ernstfall versagen, da PHP die exakte Scriptarchitektur nicht versteht!
Das Problem mit den unzuverlässigen Skripten seh ich eher umgekehrt, denn so wie es jetzt ist kann man eben das Locking vergessen.
Allerdings hast du sicher Recht, das ein fest eingebautes Locking sicher nicht allen Skripten gerecht werden kann und eine individuelle Lösung notwendig ist.
Wenn ich so über ASP.NET nachdenk, dann ist es dort eigentlich genau so (zumindest fast). Wenn man exklusiven Zugriff auf die Session haben will muss man diese explizit sperren (per Methoden-Aufruf). Gibts dafür in PHP eigentlich auch einen einfachen Befehl oder wie würde man das dort lösen?
Gruß,
Harlequin
--
<!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->-
Hi,
Wenn man exklusiven Zugriff auf die Session haben will muss man diese explizit sperren (per Methoden-Aufruf). Gibts dafür in PHP eigentlich auch einen einfachen Befehl oder wie würde man das dort lösen?
PHP sperrt automatisch. Man muß *explizit* die Exklusivität *aufheben*, wenn nicht exklusiv auf Sessiondaten zugegriffen werden soll.
Das ist z.B. dann sinnvoll, wenn man mit (I)Frames & Session arbeitet. Denn wenn man den parallelen Zugriff nicht aufhebt, dann lädt er die Seiten nicht parallel, sondern laaangsam nacheinander ...
Gruß, Cybaer
--
Man muß viel gelernt haben, um über das, was man nicht weiß, fragen zu können.
(Jean-Jacques Rousseau, Philosoph u. Schriftsteller)
-
Yerf!
PHP sperrt automatisch. Man muß *explizit* die Exklusivität *aufheben*, wenn nicht exklusiv auf Sessiondaten zugegriffen werden soll.
Hm, das dachte ich ja ursprünglich auch (daher die Anmerkung von mir in meiner ersten Antwort), denn PHP speichert die Session ja in einer Datei, die am Sessionstart eingelesen und am Ende in einem Stück wieder geschrieben wird. Ein paralleler Zugriff würde Datenverlust bedeuten der eigentlich nicht gewollt sein kann...
Das ist z.B. dann sinnvoll, wenn man mit (I)Frames & Session arbeitet. Denn wenn man den parallelen Zugriff nicht aufhebt, dann lädt er die Seiten nicht parallel, sondern laaangsam nacheinander ...
Dann muss man aber verdammt aufpassen, wenn man Werte in der Session ändert, oder?
Gruß,
Harlequin
--
<!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->-
Hi,
Dann muss man aber verdammt aufpassen, wenn man Werte in der Session ändert, oder?
Ja, dann schon.
Gruß, Cybaer
--
Man muß viel gelernt haben, um über das, was man nicht weiß, fragen zu können.
(Jean-Jacques Rousseau, Philosoph u. Schriftsteller)
-
-
-
-
Hi,
das Detail heißt "automatisch". Ein Locking-Mechanismus ist zwingende Pflicht bei sowas!
Eben ...
Und es muss vom Script-Autor geleistet werden, keinesfalls von PHP selbst.
... und deshalb sehe ich die Pflicht hier bei PHP, wenn es schon einen solchen Mechanismus anbietet.
Das fördert auf der einen Seite unzuverlässige Scripte (weil Autoren nachlässig werden -> register_globals)
Was hat das mit Sessionfilelocking zu tun?
und kann auf der anderen Seite im Ernstfall versagen, da PHP die exakte Scriptarchitektur nicht versteht!
PHP muss nicht viel verstehen - es muss nur wissen, so lange eine Scriptinstanz eine Sessiondatei offen hat, hat da keine weitere ihre Griffel dranzulegen; und dafür sorgt PHP im allgemeinen auch zuverlässig.
MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak.-
Lieber ChrisB,
| Und es muss vom Script-Autor geleistet werden, keinesfalls von PHP selbst.
... und deshalb sehe ich die Pflicht hier bei PHP, wenn es schon einen solchen Mechanismus anbietet.
ich merke, dass wir an zweierlei Dinge denken und daher aneinander vorbei argumentieren. Du denkst anscheinend (ausschließlich?) an die Session-Datei. Ich dagegen dachte an eine weitere Datei, die sämtliche Schreibvorgänge eines PHP-Scripts gegen andere Scriptinstanzen absichert. Daher schrieb ich
| und kann auf der anderen Seite im Ernstfall versagen, da PHP die exakte Scriptarchitektur nicht versteht!
Und mein Vergleich
| Das fördert auf der einen Seite unzuverlässige Scripte (weil Autoren nachlässig werden -> register_globals)
Was hat das mit Sessionfilelocking zu tun?
sollte aufzeigen, dass manche Automatisierungen innerhalb einer Scriptsprache, in bestimmten Fällen (und ich denke wieder an Schreibzugriffe eines PHP-Scripts) zu Nachlässigkeiten bei Scriptautoren führen. So zu beobachten im Falle von register_globals. Mir war nämlich passiert, dass beim Starten einer Session plötzlich Variablen andere Werte enthielten, die ich vor dem Sessionstart initialisiert und "befüllt" hatte. Da ich lokal mit "register_globals=off" teste, dauerte es eine ganze Weile, bis ich begriff, warum mein Script sich online völlig anders verhielt.
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
-
-
-
-
-
»» Ist dieser Bug bekannt?
Wirklich die Final vom IE8? In den Betas muss wohl so ein Double-Post-Bug gewesen sein, der sollte aber angeblich behoben sein... (die Info stammt aus dem IE-Blog)
Ich habe die zwei Tage nach Veröffentlichung direkt bei microsoft.com runtergeladen. Meine Version ist: 8.0.6001.18702IC
Grundsätzlich Abhilfe schafft wohl nur ein Locking-Mechanismus, der schnell genug greift und 2 parallele Zugriffe auf die Session verhindert (sollte PHP swas nicht automatisch machen?) Ansonsten kann man das jederzeit "händisch" provozieren um dein System auszuhebeln.
Wie realisiere ich denn ein Locking, wenn Datenbank, Dateisystem und Sessions zu langsam sind?
-
Yerf!
Ich habe die zwei Tage nach Veröffentlichung direkt bei microsoft.com runtergeladen. Meine Version ist: 8.0.6001.18702IC
Hab grad keinen Vergleich da, aber sollte dann schon die aktuelle sein. Scheinbar ist der Bug noch drinn.
Wie realisiere ich denn ein Locking, wenn Datenbank, Dateisystem und Sessions zu langsam sind?
Das aktuelle System ist wenn ich Felix Antwort richtig interpretiere wohl eher nicht ausreichend anstelle von zu langsam.
Welche Möglichkeiten PHP da bietet weis ich nicht, aber ein Lock auf eine Datei oder Datenbank sollte ausreichen. (Bei manchen Datenbanksysteme gibts z.B. die Möglichkeit innerhalb einer Transaktion eine Tabelle bereits beim lesen zu sperren, so kann man verhindern, das zwischen einem Select und dem nachfolgenden Update kein anderer auf die Tabelle zugreifen kann)
Gruß,
Harlequin
--
<!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->
-
-
-
Hi,
ich hab eine php-Applikation, bei der ich einem Nutzer virtuelles Geld gutschreiben kann. Neuerdings wurde das Geld immer doppelt gutgeschrieben und das, obwohl ich Mechanismen eingebaut habe, die es über die Session verhindern, daß ein method-post-Formular zweimal abgeschickt werden kann.
Wie sehen diese Mechanismen aus?
Jetzt habe ich in den Apache-Logs gesehen, daß dieses Formular zweimal parallel vom IE8 abgeschickt wird und php noch nicht die Zeit hatte, um nach Abarbeiten des Formulars den Schutz für erneutes Absenden zu setzen.
Die Posts sind immer doppelt, allerdings nur mit dem IE8(Final):
127.0.0.1 - - [31/Mar/2009:14:57:25 +0200] "POST /foo.php HTTP/1.1" 200 7743
127.0.0.1 - - [31/Mar/2009:14:57:25 +0200] "POST /foo.php HTTP/1.1" 200 7743Nur weil sie zur gleichen *Sekunde*, die in der Datenverarbeitung immer noch ein verdammt langer Zeitraum ist, reinkommen, werden sie trotzdem nicht "parallel" abgearbeitet, sondern sequentiell.
Wie das Locking der Sessiondatei hierbei versagen soll, kann ich mir gerade nicht vorstellen.
MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak.