Prüfung ob User eingeloggt ist verursacht 503 Error

Wir benutzen Shopware 5.0.3 (aktuell nicht möglich das upzudaten) und bekommen sehr oft einen 503 Error.

Stack trace
#0 /var/www/vhosts/spuernasen-4you.de/httpdocs/engine/Library/Zend/Session/Namespace.php(414): Zend_Session_Abstract::_namespaceUnset('Shopware', 'sUserMail')
#1 /var/www/vhosts/spuernasen-4you.de/httpdocs/engine/Library/Enlight/Components/Session/Namespace.php(54): Zend_Session_Namespace->__unset('sUserMail')
#2 /var/www/vhosts/spuernasen-4you.de/httpdocs/engine/Shopware/Core/sAdmin.php(1371): Enlight_Components_Session_Namespace->offsetUnset('sUserMail')
#3 /var/www/vhosts/spuernasen-4you.de/httpdocs/engine/Shopware/Plugins/Community/Frontend/StcomTemplateFeuerbaer/Controllers/Widgets/StcomEasyLogin.php(30): sAdmin->sCheckUser()
#4 /var/www/vhosts/spuernasen-4you.de/httpdocs/engine/Library/Enlight/Controller/Action.php(159): Shopware_Controllers_Widgets_StcomEasyLogin->showLoginWindowAction()
#5 /var in /var/www/vhosts/spuernasen-4you.de/httpdocs/engine/Library/Zend/Session/Abstract.php on line 112

mod_fcgid: stderr: PHP Fatal error: Uncaught exception 'Zend_Session_Exception' with message 'Zend_Session is currently marked as read-only.' in /var/www/vhosts/spuernasen-4you.de/httpdocs/engine/Library/Zend/Session/Abstract.php:112

 

Code in StcomEasyLogin.php:

class Shopware_Controllers_Widgets_StcomEasyLogin extends Enlight_Controller_Action {
	static protected $userLoggedIn;

	/**
	 * Login window action handler
     * @public
     * @return void
	 */
	public function showLoginWindowAction() {
		self::$userLoggedIn = Shopware()->Modules()->Admin()->sCheckUser();
		$this->View()->assign('sUserLoggedIn',self::$userLoggedIn);
		return;
	}

}

Ich habe schon gelesen, dass diese Prüfung anscheinend nicht unbedingt zuverlässig funktioniert. Allerdings weiß ich gerade nicht wie ich das umbauen müsste, dass es sauber funktioniert.

Könnt ihr mir helfen oder liegt der Fehler woanders?

Vielen Dank schon mal.

Zu UserLoggedIn gibt es gefühlt 100 Themen im Forum. Da hat bestimmt eines die Lösung.

Hab ich schon. Ist sehr komisch. Hab es auch mal umgeschrieben auf 

Shopware()->Modules()->Admin()->sGetUserData()

Dann passiert der Fehler dort. Im Quellcode von Shopware wird auch 

Shopware()->Modules()->Admin()->sCheckUser();

benutzt und da gibt es keine Errors.

 

Wäre für jede Hilfe dankbar. Gerne auch gegen Bezahlung!

Ich weiß den genauen Zusammenhang nicht mehr, aber das hatte irgendwas mit Bots zu tun glaube ich. Es kann auf jeden Fall vorkommen, dass unter bestimmten Umständen die Session nicht schreibbar ist. Die sCheckUser schreibt halt immer was in die Session und das funktioniert nicht. Ich meine mich zu erinnern, dass das z.B. für den Google-Crawler fatal ist, weil der dann überall nur noch Fehlermeldungen bekommt (je nachdem wo das Plugin überall eingesetzt wird).

Ich hatte das dann so gelöst, dass ich das ganze in einen try/catch-block geschrieben habe und die Exception abgefangen habe. Wenn eine Exception auftaucht habe ich dann einfach meine $loggedIn Variable auf false gesetzt.

1 Like

Hi,

das ist zZt tatsächlich so: Bei Bots wird die Session für Writes gesperrt, um die Datenbank nicht unnötig mit “leeren” Sessions zu befüllen. Im Standard ist das soweit kein Problem - allerdings laufen Drittplugins bisweilen in die “Falle”. Entsprechend wird das bei uns wohl so umgestellt, dass Bot-Sessions eine Dummy-Session erhalten, die nicht persistiert wird. Ich weiß gerade nicht, ob das schon drin ist - aber da sind wir dran. Bis dahin müsstet ihr das wie von @t2oh4e‍ vorgeschlagen selbst abfangen - oder händisch darauf prüfen, ob es sich um eine Bot-Session handelt, bevor ihr schreibt.

Besten Gruß,

Daniel

1 Like

Ah ok, super. Das mit den Bots hatte ich gelesen. Das macht dann auch Sinn, weil die Errors unsere SEO Agentur gemeldet hat und dass wir dringend eine Lösung brauchen weil sonst der Shop in Google abgewertet wird.

@t2oh4e‍ dann werde ich es mit try/catch Block versuchen.

@steinsoftware schrieb:

Zu UserLoggedIn gibt es gefühlt 100 Themen im Forum. Da hat bestimmt eines die Lösung.

@steinsoftware, gefühlt ja, aber keine Lösung. Der Link zu dieser Doku geht auch nicht mehr: http://wiki.shopware.de/Globale-Variablen-im-Template-verwenden_detail_938_715.html

Gibt es einen neuen Weg?

@NextMike‍ bei mir hat das mit dem Try/Catch wunderbar funktioniert. Seitdem keine 503 Errors mehr.

@NextMike schrieb:

Der Link zu dieser Doku geht auch nicht mehr: http://wiki.shopware.de/Globale-Variablen-im-Template-verwenden_detail_938_715.html

Gibt es einen neuen Weg?

Moin,

der Artikel ist den Aufräumarbeiten zum Opfer gefallen, da er aber doch hier und da noch genutzt wird, hab ich ihn erstmal wieder aktiviert. Nebenbei hab ich ein Ticket erstellt, dass dafür ein Folgeartikel in der aktuellen Developer-Doku erstellt wird. Sobald der fertig ist, richten wir auch eine Weiterleitung ein.

1 Like

Vielleicht hilft das noch etwas weiter: https://forum.shopware.com/discussion/comment/188142