Thema: Problem mit UserState Variable

Hallo,

ich habe ein Problem, bei dem ich langsam nicht mehr durchblicke.

1. Auf meiner Seite lade ich via Flashuploader ein Bild auf den Server.
2. Funktion upload() speichert es temporär und schreibt den Pfad ins UserState Objekt.
3. Funktion upload() schickt als Antwort (NUR ZUM TESTEN) den Pfad an die Seite zurück. Das bleibt jedoch nicht so.
4. Daraufhin wird via AJAX ein Formular mit anderen Daten abgeschickt.
5. Funktion save() validiert das Formular, liest den zuvor gespeicherten Pfad aus dem UserState Objekt und soll ihn erneut schicken. Allerdings steht der Pfad nicht mehr im UserState.

Warum? Was mache ich falsch?

Zitat von Anneminchen

Niemand, der Rat weiß? Benutzt das niemand außer mir?

Doch, bestimmt.
Aber vielleicht können andere mit deinen Infos genauso wenig anstellen, wie ich.

Ohne zu wissen wie deine Funktionen und Formulare arbeiten bzw. zum Bespiel der Request aussieht ist das alles nur raten und nachfragen. Darauf haben die meisten hier aber keine Lust.

Wird denn der Pfad überhaupt richtig gespeichert? Hast du an "anderer Stelle" die Möglichkeit die Variable nach dem setzen wieder auszulesen? ( Siehst nun gehts schon los mit raten )

Erkläre einfach ein wenig mehr oder hänge die betreffenden Dateien hier ran.
Dann kann evtl. jemand drauf schauen.

Aber vielleicht können andere mit deinen Infos genauso wenig anstellen, wie ich.

Wie jetzt? Ich habs doch extra Schrittweise beschrieben, da erfahrungsgemäß lange Erklärungen erst garnicht gelesen bzw. beantwortet werden. Also nochmal.

1. Flashuploader schickt Bild an Controller

PHP-Code:

index.php?option=mycomp&view=test&task=UPLOAD    // nur groß geschrieben, um den Unterschied zu markieren 


2. Controller 'Test' nimmt in Funktion UPLOAD() die Nachricht entgegen. Anschließend setzt er (immer noch in derselben Funktion) eine State-Variable und schickt sie zum Test als Antwort an den View zurück.

PHP-Code:

// Verarbeitung von $_FILES
...
...

$app->setUserState('testview.test', 'bestanden');

echo json_encode(array(
   'error':'',
   'code':'200',
   'test':$app->getUserState('testview.test', 'nicht bestanden');
   'message': 'Message 1'
)); 


3. In meinem View wird die Antwort geprüft. Es kommt zurück:

"{"type":"message","code":200,"test":"bestanden","message":"Message 1"}"

Die Userstate Variable ist also vorhanden. Da kein Fehler zurück kam, wird nun automatisch ein Formular abgeschickt an.

PHP-Code:

index.php?option=mycomp&view=test&task=SAVE    // nur groß geschrieben, um den Unterschied zu markieren 


4. Controller 'Test' nimmt nun in Funktion SAVE() die Nachricht entgegen und ruft da die Userstate Variable ab (die zuvor in Funktion upload() gesetzt wurde), weil er diese an den View zurück schicken soll.

PHP-Code:

// Verarbeitung von $_POST
...
...

echo json_encode(array(
   'error':'',
   'code':'200',
   'test':$app->getUserState('testview.test', 'nicht bestanden');
   'message': 'Message 2'
)); 


5. Der View prüft die Antwort wieder. Aber dieses Mal kommt zurück:

"{"type":"message","code":200,"test":null,"message":"Message 2"}"

Was bedeutet: Die Variable steht nicht mehr in der Session.

Wird denn der Pfad überhaupt richtig gespeichert?

Ja, da ich beim Abrufen einen Standardwert als Alternative übergebe, um zu testen, dass die Variable richtig gesetzt wurde.

PHP-Code:

$app->setUserState('testview.test', 'bestanden');

$app->getUserState('testview.test', 'nicht bestanden'); 


Da innerhalb derselben Funktion 'upload()' das Abrufen den korrekten Wert 'bestanden' holt, in der anderen Funktion 'save()' jedoch nicht, hier kommt 'nicht bestanden' zurück, bin ich sicher, dass die Variable verloren geht.

Besser als so kann ich es nicht beschreiben.

Sofern es sich um den Entwicklerbereich handelt, habe ich gegensätzliche Erfahrungen gemacht. Ich glaube je mehr man sich hier die Mühe macht sein Problem zu schildern, desto eher sind die Supporter bereit sich dem anzunehmen. In diesen Sinne, Danke. Zum Anliegen; auf den ersten Blick (überflogen): myview != testview => different UserState ?

In Deiner Beschreibung wird in den ersten Codeschnipseln 'testview' verwendet, im letzten Schnipsel dagegen 'myview'. Falls das Auszüge aus dem Code sind den Du verwendest, dann hast Du eben nicht den gleichen Namespace verwendet. Darauf wollte Matrikular wohl aufmerksam machen.

Nun zum eigentlichen Problem:
Normalerweise geht (bei J1.5 - siehe unten) kein UserState verloren solange die Session "steht". Kann es sein, dass der Session-Cookie bei irgendeinem Request verloren geht, und dadurch dann eine neue Session angelegt wird, die Deine States nicht mehr beinhaltet? Ich würde jedenfalls im FireBug mal ganz genau die Requests/Responses anschauen und dabei drauf achten, ob sich am Cookie was ändert. Die Daten stehen übrigens serialisiert im Feld data in der Tabelle DeinPrefix_session. Dort würde ich auch mal kontrollieren ob das gewünschte Zeug drinsteckt - strings kann man ja auch in serialisierter form schön sehen.

Und noch ne Frage: Wir sind hier zwar im 1.5er Forum, aber kann es sein, dass Du das zufällig auf 1.6 probierst?
Hintergrund meiner Frage: Hatte neulich fast genau den selben Effekt unter 1.6 (der Code hat aber unter 1.5 einwandfrei funktioniert).
Nachdem ich's gefunden hatte, bin ich fast vom Stuhl gefallen:
Bei 1.6 wurde das data field in der session table von LONGTEXT (bei 1.5) auf VARCHAR(20480) (bei 1.6) gekürzt. Da ausserdem keine Prüfung auf Überschreitung der Maximallänge im core stattfindet, hat dies dann bei mir (mit zugegeben recht grossen Daten im UserState) dazugeführt, dass die States ganz mysteriös verstümmelt waren ... . Hierzu gibts bei 1.6 mittlerweile auch einen Bugtracker-Eintrag.
Begründung auf meine Nachfrage auf der Developer-Liste war: Performance: MySQL kann tabellen als memory-table nur dann verwenden wen darin keine blobs drinstecken. - Meiner Meinung nach recht fadenscheinig, denn auf heavy-load-sites kann man ja die session auch über memcached abfackeln.

Hallo Fritz,

danke für deine Antwort.

In Deiner Beschreibung wird in den ersten Codeschnipseln 'testview' verwendet, im letzten Schnipsel dagegen 'myview'. [...] Falls das Auszüge aus dem Code sind den Du verwendest...

Ja, du hast Recht. Die Bezeichner hab ich für das Beispiel frei erfunden. In besagtem Beitrag ganz unten wollte ich nur nochmal zeigen, dass ich beim Setzen und Abrufen denselben Namespace verwende. Das ist wichtig zu beachten! Sorry für die Verwirrung. Danke euch beiden für den Hinweis.

kann es sein, dass Du das zufällig auf 1.6 probierst?

Nein, ich verwende zwar die Model Klassen JModelItem und JModelList aus der Version 1.6, aber ich entwickle auf 1.5. Bezieht sich dein beschriebenes Szenario auf besagte Modelklassen? Dann hab ich ein Problem. Wobei ich kaum nennenswert viele Daten in die Session schreibe. Höchstens mal ein Formular zum validieren der Felder oder vereinzelte Felder. Die Stringlänge dürfte dadurch jedoch nicht bis über die Grenze ausgereizt werden.

Kann es sein, dass der Session-Cookie bei irgendeinem Request verloren geht, und dadurch dann eine neue Session angelegt wird, die Deine States nicht mehr beinhaltet?

Mhm... Gute Frage. Ich hab in Firebug nachgeschaut. Im Block 'Header' steht:

Antwort-Header
Date: Sun, 27 Mar 2011 02:46:18 GMT
Set-Cookie: ZDEDebuggerPresent=php,phtml,php3; path=/
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Keep-Alive: timeout=5, max=96
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

Anfrage-Header
Host test.local
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16
Accept: application/json
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
X-Requested-With: XMLHttpRequest
X-Request: JSON
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Referer: http://test.local/index.php?option=m...save&Itemid=32
Content-Length: 325
Cookie: ZDEDebuggerPresent=php,phtml,php3; 0ac344bc02c614d51d7ea50f350185ef=uk1cblbmoq6sho9ur 980t60su2; 9b1252547e258e76f564778ac72b90b0=8rrgfso2bs2a7ugjq 2tvm3f6h3

Da steht zwar was von Cookie, aber augenscheinlich nichts der Art

test=bestanden

Zitat von Anneminchen

Moin,
Bezieht sich dein beschriebenes Szenario auf besagte Modelklassen?

Nein, das Problem besteht unabhängig von den drüberliegenden Klassen. Insofern bist Du unter 1.5 nicht betroffen.

Zitat von Anneminchen

Mhm... Gute Frage. Ich hab mich bislang nicht mit Firebug Debugging auseinander gesetzt. Hab mich zu sehr an die var_dump(); jexit(); Methode gewöhnt weil man ja in Joomla! leider nicht anders debuggen kann. Jedoch werde ich das gleich mal prüfen. Danke für den Hinweis auf die Stelle, wo ich suchen muss.

In dem Fall noch folgenden Tipp:
Installier Dir mal JDump. Das macht im Prinzip das Gleiche wie var_dump, nur hübsch formatiert in einem separaten Popup-Window (ohne den eigentlichen content zu stören).
Und dann gib damit mal vor dem getUserState() die Joomla session ID aus:

PHP-Code:

$session =& JFactory::getSession();
dump($session->getId(), 'SID1'); 


Die muss natürlich konstant bleiben. Ich tippe mal blind auf den Ajax-Request, der das Cookie "vergisst". Der 2. Parameter von dump(...) ist übrigens ein beliebiger String, der die Stelle des Aufrufs in der Anzeige identifiziert.

Edit: Und nochwas: die SID ist auch der key für die session table in der DB... falls du den select mit mysql auf der shell absetzen willst...

Zitat von Anneminchen

Da steht zwar was von Cookie, aber augenscheinlich nichts der Art ...

Nee, das funktioniert etwas komplexer:

Wenn Joomla eine Session anlegt, generiert es eine eindeutige ID (32stellige hex-Zahl). Diese wird einerseits im Cookie gesetzt, andererseits als key für die Session-Table verwendet. Wenn Du setUserState aufrufst, dann wird dein State in einem UserState-Objekt abgelegt, welches zunächst nur im Speicher am JApplication-Object mit dranhängt. Wenn ein Request fertig bearbeitet wurde, dann wird als letztes dieses UserState-Objekt serialisiert und der resultierende String unter dem vorher generierten key in der Session-Table abgelegt. Wenn dann der nächste Request kommt, und dabei das Session-Cookie wieder präsentiert, dann wird mit der ID das UserState-Objekt wieder aus der Session-Tabelle restauriert. Auf diese Weise braucht man immer nur einen Hash im Cookie ablegen und hat trotzdem persistente Daten über mehrere Requests hinweg.

Dein State steht also in jos_session.data. Und den kannst Du (z.B. auf der kommandozeile mit mysql) mit folgender query anschauen.
select data from jos_session where session_id = 'DeinAktuellerSessionHash';

Als Resultat siehst Du dann einen ziemlich langen String. Etwa wie:

Code:

__default|a:7:s:15:"session.counter";i:2;s:19:"session.timer.start";i:1301175511;s:18:"session.timer.last";i:1301175511;s:17:"session.timer.now";i:1301175517;s:22:"session.client.browser";s:87:"Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16";s:8:"registry";O:9:"JRegistry":3:{s:17:"_defaultNameSpace";s:7:"session";s:9:"_registry";a:1:{s:7:"session";a:1:{s:4:"data";O:8:"stdClass":0:{}}}s:7:"_errors";a:0:{}}s:4:"user";O:5:"JUser":19:{s:2:"id";s:2:"63";s:4:

Und irgendwo in dem String tauchen dann Deine Daten auf als s:14:"test=bestanden" (Das s bedeutet "dies ist ein String", danach kommt die Länge, danach der Wert).

Wie in meinem anderen Post: Kontrollier aber erst mal nur den Session-Hash. Der muss bei den aufeinanderfolgenden Requests konstant bleiben. Wenn nicht, dann ist es eine neue Session.


Da kommt mir grad was:
Nachtigall ....

Du sagtest vorhin dass Du immer mit var_dump und exit debuggst. Das exit bricht natürlich komplett ab, ohne dass Joomla die Chance hat etwas in die session-table zu speichern...