Fatal error: Session validation failed

[leolicai]

If computer only one browser. then open the size is ok.
If have other browser, like open the site use chrome. it's ok, then open the site use firefox.
The session will trow exception.
It's an abominable question.
The zend-session have half year no updated. The ZendFramework is ok?

[waltertamboer]

I'm experiencing similar problems. Problem is that this is happening very sporadically. I put var_dump's in every validator and waited for it to happen again. I managed to track this down to the Id validator.

.../src/Validator/Id.php:77:string '$saveHandler: files' (length=19)
.../src/Validator/Id.php:78:string 'session_id(): DHPZ3QIiIuYksTV2elsBH2' (length=36)
.../src/Validator/Id.php:79:string '$this->id: jkwKiSASxjK-BVvmv2STq3' (length=33)
.../src/Validator/Id.php:80:string '$hashBitsPerChar: 5' (length=19)
.../src/Validator/Id.php:81:string '$pattern: #^[0-9a-v]*$#' (length=23)
.../src/Validator/Id.php:82:string '$id: jkwKiSASxjK-BVvmv2STq3' (length=27)

The regular expression obviously fails because of $id containing a dash and uppercase characters.

When the hash bits are set to 6, the validation succeeds. The question I have is, why does the session id contains that value while the hash bits are set to 5.

[Mecanik]

I have the same issue... after I have applied SSL on the production server. And unfortunately I have no idea how to fix it....

[weierophinney]

I'd love to fix this, but without a way to reproduce it, I have no way to proceed; any attempted fix would be guesswork at this point.

If somebody who experiences the issue is able to isolate and create a reproduce case, please post it here or via a pull request with a failing test.

Thanks!

[rolandoisidoro]

Hi,

was able to reproduce this issue. My session has 2 validators assigned Session\Validator\RemoteAddr and Session\Validator\HttpUserAgent. During development I was logged in to my app using zend-session and had my browser updated and so the HTTPUserAgent changed.

I consider this to be the expected behaviour, so IMO you have 2 choices:

1. Disable Session\Validator\HttpUserAgent;
2. Add a try catch block to your $session->start() so you can handle the Exception.

Rolando Isidoro

[tempfirstuser]

I have this exception only in google chrome (in firefox everything is fine):

PHP Fatal error:  Uncaught Zend\\Session\\Exception\\RuntimeException: Session validation failed in /mysite/vendor/zendframework/zend-session/src/SessionManager.php:162
\nStack trace:
\n#0 /mysite/module/Application/src/Module.php(104): Zend\\Session\\SessionManager->start()
\n#1 /mysite/vendor/zendframework/zend-eventmanager/src/EventManager.php(322): Module\\Application\\Module->onBootstrap(Object(Zend\\Mvc\\MvcEvent))
\n#2 /mysite/vendor/zendframework/zend-eventmanager/src/EventManager.php(171): Ze
nd\\EventManager\\EventManager->triggerListeners(Object(Zend\\Mvc\\MvcEvent))
\n#3 /mysite/vendor/zendframework/zend-mvc/src/Application.php(161): Zend\\EventManager\\EventManager->triggerEvent(Object
(Zend\\Mvc\\MvcEvent))\n#4 /mysite/vendor/zendframework/zend-mvc/src/Application.php(273): Zend\\Mvc\\Application->bootstrap(Array)
\n#5 /mysite/public/index.php(48): Zend\\Mvc\\Application::init(Array)
\n#6 {main}\n  thrown in /mysite/vendor/zendframework/zend-session/src/SessionManager.php on line 162

I removed all session validators. I remove all cookies but site opens in google chrome only in one mode: desktop or mobile. It looks like it is related to one simple fact:
when I open site in firefox in both mode (desktop and mobile) there is the same header "User-Agent",
but in case of google chrome "User-Agent" is different for desktop and mobile with the same session cookies.

[tempfirstuser]

If somebody who experiences the issue is able to isolate and create a reproduce case, please post it here

I have added reproduced case up here in my post. But it doesn't looks like a bug at least in my case because of google chrome.

[jcaillot]

Could you also post (if of any relevance) the chrome web console output ?

[michalbundyra]

@tempfirstuser

but in case of google chrome "User-Agent" is different for desktop and mobile

I believe it is correct behaviour. As you noted the user agent is different when you are switching between mobile and desktop view (developer tools).

So session is created with one UserAgent and when you change the it and refresh the page session validation is failing due to different UserAgent. Exactly the same behaviour you'll get with RemoteAddr but this might be harder to reproduce.

The behaviour is described in the documentation:
https://docs.zendframework.com/zend-session/validator/
so if validation fails the exception is thrown.

In general I am not sure if it is correct behaviour to throw exceptions, I think I would prefer new session to be generated in case of failed validation, but this will be BC Break.
Now you must add try...catch because it is possible that some people switch mobile/desktop view in chrome, or - for IP changes between page refreshes on unstable network (where internet provider changes IPs)

@weierophinney / @Xerkus What do you think?

[tempfirstuser]

@jcaillot here is:

Request headers of desktop mode for google chrome:

GET / HTTP/1.1
Host: excms.net
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: PHPSESSID=8d75s67bp2ovu9pd02hivqjc96

After that, I switch to the mobile mode and get HTTP ERROR 500. With this error I can't see any cookies or headers. Next what I am doing I delete all cookies and cache data of the page. After that I refresh the page in that same mobile mode and here is request headers of mobile mode in google chrome:

GET / HTTP/1.1
Host: excms.net
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A372 Safari/604.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: PHPSESSID=ir5k4k71ks3in48u05q3r5kap6

In this example cookies is different because I delete them all previously, but you should pay attention at different "User-Agent" of desktop and mobile mode. In the firefox "User-Agent" is the same in both modes and cookies is the same too.

[tempfirstuser]

@webimpress but I have removed all validators:

    'session_manager' => [
        'validators' => [
            //RemoteAddr::class,
            //HttpUserAgent::class,
        ],
    ],

And the behavior of google chrome is the same. But this is true only for remote server. At my local server I don't get any error in google chrome when switching between modes.

[tempfirstuser]

I have deployed my project at first time yesterday at my remote server. At my local server I have added APPLICATION_ENV variable to apache2 config. At remote server I did not add this var to the apache2. At local server my /data/cache folder is emty. But at remote server I see two new files inside /data/cache.
these files:
module-classmap-cache.application.module.cache.php
module-config-cache.application.config.cache.php

After removing these cache-files site works fine in both modes: desktop and mobile at google chrome. But it works without session validators. @webimpress , thank you for your help at zf chat.

[weierophinney]

This repository has been closed and moved to laminas/laminas-session; a new issue has been opened at laminas/laminas-session#9.