Probleme mit Sessions in PHP (getKey und setKey)

Hallo,

ich hab ein Problem mit der typo3-Session:

Aus einem Formular von einer Seite "A" werden über die Variablen $_Post[inhalt1],$_Post[inhalt2],... usw auf der Seite "B", die Daten in einem Array gespeichert. Die Seite "B" ist dabei über einen direkten Link mit Seite "A" verbunden. Dieses Array wird anschließend über "setKey()" in der typo3-Session gespeichert.

$datensatz = array();
$datensatz[0] = $_POST['inhalt1'];
$datensatz[1] = $_POST['inhalt2'];
$datensatz[2] = $_POST['inhalt3'];
$datensatz[3] = $_POST['inhalt4'];
					$GLOBALS['TSFE']->fe_user->setKey('ses','datensatz',$datensatz);	$GLOBALS["TSFE"]->storeSessionData();

Anschließend lasse ich mir (ebenfalls auf der Seite "B") zum Testen, die gespeicherten Werte aus der Session ausgeben:

$test = array();
$test = $GLOBALS['TSFE']->fe_user->getKey('ses','datensatz');
echo $test[0]." - ".$test[1]." - ".$test[2]." - ".$test[3]." - ".$test[4];

Diese werde korrekt angezeigt!

Jetzt zum Problem:
Wenn ich nun über einen direkten Link auf die Seite "A" wieder zurückkehre und dort die gespeicherte Session über "getKey()" wieder auslese, stimmen die Werte nicht mehr:

$datensaetze = array();
$datensaetze = $GLOBALS['TSFE']->fe_user->getKey('ses','datensatze');

echo $datensatze[0]." - ".$datensatze[1]." - ".$datensatze[2]." - ".$datensatze[3];

Wenn ich diesen Vorgang öfter wiederholen, treten unterschiedliche Fälle auf:
1. die Session ist komplett leer
2. die Session ist mit alten Werten gefüllt
3. die Session ist mit den richtigen Werten (die vorher auch auf Seite "B" angezeigt wurden) gefüllt.

Ich konnte leider noch keine Regelmäßigkeiten ausmachen, wann welcher Fall eintritt.

In typo3 habe ich für die entsprechenden Seiten die Option "nicht cachen" aktiviert, die das serverseitige Cachen der fertigen Seite deaktiviert... aber leider auch ohne Erfolg!

Ich bin am verzweifeln!!! #angry#

Kann mir jemand helfen?
Hat jemand schon einmal ein ähnliches Problem gehabt?

Ich danke euch!

Gruß Stepo

$GLOBALS["TSFE"]->fetchSessionData();

Hey, danke...ich kann es bloß im Moment leider nicht ausprobieren.

was macht der Befehl $GLOBALS["TSFE"]->fetchSessionData() genau?

Gruß und noch einen schönen Abend...

fetch?

Danke, aber was fetch auf deutsch bedeutet weiß ich auch.

Ich wollte einfach nur gerne den Unterschied wissen zwischen "$GLOBALS['TSFE']->fe_user->getKey('ses','datensatz');" und dem Aufruf "$GLOBALS["TSFE"]->fetchSessionData();".

Hat fetchSessionData() gar keine EIngabeparameter?

Das sollte Klarheit schaffen:

* Fetches the session data for the user (from the fe_session_data table) based on the ->id of the current user-session.
* The session data is restored to $this->sesData
* 1/100 calls will also do a garbage collection.

Das mit "fetchSessionData()" hatte ich wirklich auf Seite "A" vergessen, aber leider liegt der Fehler immernoch vor.

Das Problem scheint wohl auf der Seite "B" zu liegen.
Nachdem die Werte dort richtig in der Variablen "$GLOBALS['TSFE']->fe_user->sesData" gespeichert und dann auch ausgegeben wurden, will ich diese in der Session-Datenbank mit "storeSessionData()" speichern. Hier scheint dann wohl etwas schief zu laufen.

Durch den Aufruf "$GLOBALS['TSFE']->fe_user->fetchSessionData()" werden die Werte wieder aus der Seesion-Datenbank geholt und in der Variable "$GLOBALS['TSFE']->fe_user->sesData" gespeichert. Wenn ich nun mit "$GLOBALS['TSFE']->fe_user->getKey('ses','datensaetze')" die Werte in einem Array speichere und dann ausgebe, ist diese Ausgabe fehlerhaft bzw. meistens fehlerhaft (fehlerhaft == die vorhergehenden breits verfallenden Sessionwerte).
Ich hab euch schon direkt in der Datenbank nachgeschaut, dort sind die Werte dann auch falsch.

Hier mein Codeauszug von der Seite "B":

$datensatz = array();
$datensatz[0] = $_POST['inhalt1'];
$datensatz[1] = $_POST['inhalt2'];
$datensatz[2] = $_POST['inhalt3'];
$datensatz[3] = $_POST['inhalt4'];
                                              $GLOBALS['TSFE']->fe_user->setKey('ses','datensatz',$datensatz);

$test = array();
// Daten werden aus "sesData" geholt (diese Ausgabe ist richtig)
$test = $GLOBALS['TSFE']->fe_user->getKey('ses','datensaetze');
echo "<br>".$test[0]." - ".$test[1]." - ".$test[2]." - ".$test[3]." - ".$test[4]."<br>";
			
// Speicher die Werte aus "sesData" in der DB
$GLOBALS["TSFE"]->fe_user->storeSessionData();

		
// Daten von "sesData" werden mit den Daten aus der DB aktualisiert
$GLOBALS['TSFE']->fe_user->fetchSessionData();

// Daten werden aus der aktualisierten "sesData" geholt (hier werde die falschen Werte ausgegeben)
$test = $GLOBALS['TSFE']->fe_user->getKey('ses','datensaetze');
echo "<br>AUS sesData: ".$test[0]." - ".$test[1]." - ".$test[2]." - ".$test[3]." - ".$test[4]."<br>";

Was mich total verrückt macht, ist die Tatsache, dass das Speichern mal funktioniert und mal nicht. Es ist überhaupt keine regelmäßigkeit dort festzustellen.

Hoffe ihr könnt mir helfen!

Also, ich hab den Fehler leider immernoch nicht gefunden.
Mir scheint es aber so, als würde die Funktion "storeSessionData()" nicht immer die Datenbank aktualsieren... jedoch habe ich keine Ahnung wann und wieso?!?

Mmh...

$GLOBALS['TSFE']->fe_user->setKey('ses','[b]datensatz[/b]',$datensatz);
...
$test = $GLOBALS['TSFE']->fe_user->getKey('ses','[b]datensaetze[/b]');

Da wundere ich mich doch erstmal darüber daß du überhaupt Daten wieder ausgelesen bekommst #giggle#

Ansonsten ist das Problem nicht nachvollziehbar,
die Daten werden sauber gespeichert und wieder ausgelesen.
Die POST-Daten sollte man vor dem Speichern in die DB natürlich säubern,
so hast du dir nämlich gerade ein prima Sicherheitsloch gebastelt.

Du bist absolut sicher:
- daß deine TYPO3-Installation fehlerfrei über die Bühne ging?
- daß dein cookie-handling sauber funktioniert ?
- daß deine FE-Verbindung dauerhaft mit der gleichen IP besteht?
Ansonsten sieht TYPO3 in dir nämlich ständig einen neuen FE-User und will dir die Daten des vorigen Users natürlich nicht preisgeben...

Variable setzen (KEIN Array – muss serialisiert werden):

$GLOBALS['TSFE']->fe_user->setKey(
            'ses',
            'datensatz',
            serialize($datensatz)
        );
$GLOBALS['TSFE']->storeSessionData();

Variable auslesen:

        $irgendwas = $GLOBALS['TSFE']->fe_user->getKey(
            'ses',
            'datensatz'
        );
$irgendwasBesseres = unserialize($irgendwas);

... ich glaub, bei Dir hängt es am Array, das der nicht verkraftet... :o

chris3 schrieb

Variable setzen (KEIN Array – muss serialisiert werden):

... ich glaub, bei Dir hängt es am Array, das der nicht verkraftet... :o

Nein, das stimmt nicht,
du kannst sehr wohl ein Array speichern.

	/**
	 * Returns session data for the fe_user; Either persistent data following the fe_users uid/profile (requires login) or current-session based (not available when browse is closed, but does not require login)
	 *
	 * @param	string		Session data type; Either "user" (persistent, bound to fe_users profile) or "ses" (temporary, bound to current session cookie)
	 * @param	string		Key from the data array to return; The session data (in either case) is an array ($this->uc / $this->sesData) and this value determines which key to return the value for.
	 * @return	mixed		Returns whatever value there was in the array for the key, $key
	 * @see setKey()
	 */
	function getKey($type,$key) {
		if ($key)	{
			switch($type)	{
				case 'user':
					return $this->uc[$key];
				break;
				case 'ses':
					return $this->sesData[$key];
				break;
			}
		}
	}



	/**
	 * Saves session data, either persistent or bound to current session cookie. Please see getKey() for more details.
	 * When a value is set the flags $this->userData_change or $this->sesData_change will be set so that the final call to ->storeSessionData() will know if a change has occurred and needs to be saved to the database.
	 * Notice: The key "recs" is already used by the function record_registration() which stores table/uid=value pairs in that key. This is used for the shopping basket among other things.
	 * Notice: Simply calling this function will not save the data to the database! The actual saving is done in storeSessionData() which is called as some of the last things in index_ts.php. So if you exit before this point, nothing gets saved of course! And the solution is to call $GLOBALS['TSFE']->storeSessionData(); before you exit.
	 *
	 * @param	string		Session data type; Either "user" (persistent, bound to fe_users profile) or "ses" (temporary, bound to current session cookie)
	 * @param	string		Key from the data array to store incoming data in; The session data (in either case) is an array ($this->uc / $this->sesData) and this value determines in which key the $data value will be stored.
	 * @param	mixed		The data value to store in $key
	 * @return	void
	 * @see setKey(), storeSessionData(), record_registration()
	 */
	function setKey($type,$key,$data)	{
		if ($key)	{
			switch($type)	{
				case 'user':
					if ($this->user['uid'])	{
						$this->uc[$key]=$data;
						$this->userData_change=1;
					}
				break;
				case 'ses':
					$this->sesData[$key]=$data;
					$this->sesData_change=1;
				break;
			}
		}
	}

Danke, für eure Postings!
Leider konnte ich damit mein Problem nicht lösen. Ich muss da wohl irgendwo noch etwas falsch machen.

Das seltsame ist halt, dass die Daten manchmal richtig in die Datenbank geschrieben werden und manchmal nicht. Außerdem kommt es auch häufig vor, dass die Daten auf Seite "B" nach "storeSessionData()" richtig in der Datenbank liegen und beim zurückkehren auf Seite "A" wieder die alten Werte in der Datenbank zu finden sind.

Ich hab schon überall im Code gesucht, ob ich irgendwo noch ein Update der Datenbank mache...aber Fehlanzeige.

Dann muss ich wohl erst mal weitersuchen. o.O

Hallo stepo,

ich hatte ein ähnliches Problem: bei mir wurden die Session Daten nicht gespeichert wenn ich zwischen zwei Seiten wechselte.

Das Problem lag bei:
$GLOBALS["TSFE"]->fe_user->storeSessionData();

An und für sich ist dies richtig, jedoch arbeite zumindest ich mit mehreren Datenbanken. Daher musste ich vor diese Zeilte auf die Typo3 Datenbank umschalten:
mysql_query wäre "USE db_typo3";

Liebe Grüße,
j/n

Hallo,

du hast nicht zufällig 4.2.4 im Einsatz, dann würde ein Update auf 4.2.5 helfen

georg