vielleicht kann mir ja hier jemand auf die Sprünge helfen.
Folgende Problem: Ich versuche über ein Modul den OXID Basket remote zu befüllen. Hierzu habe ich eigentlich nur einen Wrapper um die oxcmp_basket->tobasket() implementiert.
In einem nächsten Schritt, findet dann ein Absprung in den Shop statt. Hier würde ich dann einen entsprechend befüllten Basket erwarten (ich gebe im Shop Link den URL Parameter force_sid mit). Hier scheitert jedoch im Moment der ganze Prozess. Es speichert mir den Basket einfach nicht in der Session. Ich habe jetzt mal hart in die oxSession eine Methode implementiert die schlicht den Basket speichert (self::setVar( $this->_getBasketName(), serialize( $this->getBasket() ) );). Wenn ich diese in der render() der oxcmp_basket immer aufrufe, dann habe ich nach einem Absprung auch einen befüllten Basket.
Aber das kann ja nicht Sinn der Sache sein. Vermutlich übersehe ich irgendeine Kleinigkeit.
Eventuell wird durch das die() nach dem rendern des Baskets auf der Remote Site irgend ein Stück des Frameworks nicht durchlaufen.
Nebenbei: Wo in OXID wird eigentlich der Basket in die Session geschrieben? Findet der Spass in einer der gecrypteten Klassen statt?
Versteh ich das richtig… Du springst auf eine “externe” Resource in der dann über http request der Artikel zum Basket hinzugefügt wird und dann springst du wieder zurück? Beim befüllen des Baskets müsstest du in diesem Fall darauf achten, dass die externe Resource in der IP-Trustlist (config.inc.php - $this->aTrustedIPs = array() aufgelistet wird, da sonst aufgrund des IP/User-Agent Checks die Session gekillt wird.
Also meines Wissens nach haben die Jungs von Oxid dafür den remoteAccessToken eingeführt. Den kannst du über das oxSession Objekt holen und mit übermitteln. Das verhindert den User Agent Check und lässt dich eine Session quasi ausleihen. Dann kannst du dir die aTrustedIPs sparen.
Und damit vor der Weiterleitung der Warenkorb abgespeichert wird musst du die Methode “freeze” von oxSession aufrufen.
“remoteaccess” parameter support was removed at all. Introduced “aTrustedIPs” config parameter (see config.inc.php), where shop owner defines IP addresses, for which session + cookie id match and user agent change checks are off.
[QUOTE=aggrosoft;43243]Also meines Wissens nach haben die Jungs von Oxid dafür den remoteAccessToken eingeführt. Den kannst du über das oxSession Objekt holen und mit übermitteln. Das verhindert den User Agent Check und lässt dich eine Session quasi ausleihen. Dann kannst du dir die aTrustedIPs sparen.
Und damit vor der Weiterleitung der Warenkorb abgespeichert wird musst du die Methode “freeze” von oxSession aufrufen.[/QUOTE]
Genau das freeze brauche ich und verwende ich momentan (allerding ohne das session_write_close).
Meine Frage kam schlicht auf, weil ich in OXID 2.7 ein ähnliches Modul im Einsatz hatte, in dem der Basket immer in der Session persistiert wurde, auch ohne den Aufruf des oxSession->freeze(). Ich dachte schlicht, ich habe noch etas übersehen. In der 4er scheint es nun aber so zu sein, dass durch das die() in der render() dieses Stückchen Code übersprungen wird. Aber das freeze() tut es ja hier absolut.
Hab nochmal reingeschaut, entfernt wurde nur der Support für den Parameter “remoteaccess”. Das was Aggrosoft beschreibt gibt’s noch, das ist der Parameter “rtoken”, damit kann man auf die Session zugreifen von der man das Token geholt hat.
Ich hatte mir sowas einmal vor Jahren von Thomas Dartsch für die EE2.7 bauen lassen. Vielleicht hat er da noch was oder kann dir vielleicht da weiter helfen.
aufgelistet wird, da sonst aufgrund des IP/User-Agent Checks die Session gekillt wird.