PHPSESSID und session_regenerate_id( )

[cortex]

ich untersuche gerade ein phänomen, komme mit meinem eigenen latein nicht weiter und hoffe auf anregungen / hinweise von euch.

situation:

die web-anwendung nimmt anfragen auf htm, css und js über einen frontcontroller entgegen; images laufen über direkte verlinkung der ressource. htm-anfragen stossen session_regenerate_id( TRUE ) an. ob das nun sinnvoll ist oder eine einmaliges regenerate nach einem user-login ausreichend wäre, sei bitte kein diskussionsgegenstand.

problem:

bitte schaut euch dazu den mitschnitt der HTTP-header in der anhängigen textdatei an:

zeile 001: request index.php - response ok (neue sessid)
zeile 031: request spc=iport (eingebundenes objekt) - response ok
zeile 057: request gif - response ok
zeile 082: request kat=GTstats - response ok (neue sessid)
zeile 122: request gif - response ok
zeile 137: request spc=iport - response ok
zeile 163: request kat=MTcom - response ok (neue sessid)

jetzt kommt's:

zeile 192: request css mit alter sessid - response ok
zeile 217: request gif mit alter sessid - response ok
zeile 242: request spc=iport mit der korrekten sessid und der alten sessid - response ok
zeile 266: request index.php mit der alten sessid - sitzung wird abgebrochen / erneutes login fällig

ich kann mir zwei dinge nicht eklären:

1. wieso werden die requests in 192, 217 mit der alten sessid ausgeführt
2. wie kann es sein, dass der browser 2 sessid sendet (browser-unabhängig)

cx

[DokuLeseHemmung]

Mit session_regenerate_id() stolpert man schnell in Race Conditions.
Der Browser sendet u.U. ettliche Requests quasi gleichzeitig ab.
Es gibt keine Chance das Problem zu umgehen.


Testcode:

PHP-Code:

<?php
error_reporting(E_ALL);
ini_set('display_errors', TRUE);


session_start();


//session_regenerate_id(TRUE);


sleep(2);


if(isset($_GET['frame']))
{
  echo 'Zeit: '. (time() - $_SESSION['richtzeit']) .'<br>';
  exit;
}


$_SESSION['richtzeit'] = time();


?>
<frameset rows="20%,20%,20%,20%,20%">
  <frame src="?frame=<?php echo mt_rand()?>" name="test1">
  <frame src="?frame=<?php echo mt_rand()?>" name="test2">
  <frame src="?frame=<?php echo mt_rand()?>" name="test3">
  <frame src="?frame=<?php echo mt_rand()?>" name="test4">
  <frame src="?frame=<?php echo mt_rand()?>" name="test5">
</frameset>

Die Zeiten sollten im 2 Sekunden Takt in die Frames tröpfeln.
Mit session_regenerate_id(TRUE); hagelt es Meldungen, weil das gesendetet Cookie schon veraltet ist und das TRUE die Sessiondatei schon längst entsorgt hat. Auch das weglassen des TRUE bringt nicht viel, weil dann mit veralteten Sessiondaten gearbeitet wird.

ob das nun sinnvoll ist oder eine einmaliges regenerate nach einem user-login ausreichend wäre, sei bitte kein diskussionsgegenstand.

Doch doch!
Wenn du die "gleichzeitigen" Requests nicht verhindern kannst, und das kannst du nicht, wirst du dir darum schon Gedanken machen müssen.

[cortex]

Zitat von DokuLeseHemmung

Race Conditions

hm... in diese richtung gingen auch meine überlegungen.

Zitat von DokuLeseHemmung

Der Browser sendet u.U. ettliche Requests quasi gleichzeitig ab

nun gut, aber sämtliche request (ausser bilder) laufen doch über den frontcontroller. ich bin davon ausgegangen, dass die anfragen an die index.php "seriell" verarbeitet werden. ist der webserver in der lage, die datei in mehreren "instanzen" zu lesen um parallele anfragen zu verarbeiten?

cx

ps. das phänomen gleichnamiger session-IDs, die vom browser gesendet werden, bleibt.

cx

[DokuLeseHemmung]

ich bin davon ausgegangen, dass die anfragen an die index.php "seriell" verarbeitet werden.

Nöö..
Je nach Konfiguration können tausende Prozesse nebeneinander laufen.

Die Sessionverwaltung erzwingt mit session_start() die gewünschte Serialisierung durch locken der Sessiodatei. Aber da du die SID dauernd wechselst klappt das nicht.


In meinem Beispiel sendet der Browser erst einen Request um das Frameset sammt Cookie zu erhalten. Mit diesen Cookiedaten schießt er auf einen Schlag 5 Requests ab um die Frames zu füllen. Der Wechsel der SID erfolgt also nachdem die Requests schon lange abgesetzt sind.

[cortex]

Zitat von DokuLeseHemmung

Je nach Konfiguration können tausende Prozesse nebeneinander laufen.

siehste... da fehlt's mir ein bissel an hintergrundwissen .-

dank' dir für die aufmerksamkeit,

cx