Incidentally, if you have database sessions enabled and intentionally corrupt the data field by removing the data? at the front, it suggests that files are the problem and recommends enabling DB sessions:

Error: Unable to start session. Please check that the web server has enough permission to write to these files/directories...

Incidentally, if you have database sessions enabled and intentionally corrupt the data field by removing the data? at the front, it suggests that files are the problem and recommends enabling DB sessions:

Error: Unable to start session. Please check that the web server has enough permission to write to these files/directories...

that might be just some old comment. Needs to be updated / removed. Created a PR: #13857

as for the other sessions I'm not sure this is related to the DB handler being changed as it seems to work in general when the DB handler is used. not sure if @diosmosis has any idea?

@tsteur only thing I can think of is 'files' is may be used somewhere else in the code even after https://github.com/matomo-org/matomo/blob/3.x-dev/core/Session.php#L97. Maybe that causes a problem

Could it relate to use of igbinary as session.serialize_handler in PHP's global configuration? (Changing this globally is something I can't test in production, though I could if it's possible to modify just piwik sessions.)

If there's special handling on your end (it's a custom save_handler?), it might not be binary-safe, or it might assume a certain format - though I appreciate you base64 stuff before storing it in the data field of piwik_session, which is of type text, and it seems the session created initially is correctly stored.

[As for #13857, that change didn't seem to address the minor secondary issue raised; it still assumes that if there's a session error, you must not be using the database handler, so it should recommend it if installed. It doesn't envisage the possibility that an error was thrown by the already-enabled database session handler.]

created another PR #13864 for the message.

Looking at the code when you set session_save_handler = in config I think it uses the PHP internal session handler (whatever is configured in PHP, it is usually files by default).

I presume you also get the problem when setting session_save_handler = dbtable? For some reason the DB table session handler doesn't seem to work for you by the sounds. Not sure if it could be related to the serialize handler. It being related to igbinary sounds quite reasonable to me though.

Any chance you could try this patch in production? https://github.com/matomo-org/matomo/pull/13865/files

I tried that and I no longer get a form error - and inside the database, it is now storing the typical JSON format. The data within the session data decodes to (with own censoring):

a:4:{s:4:"__ZF";a:1:{s:11:"Login.login";a:1:{s:4:"ENVT";a:1:{s:5:"nonce";i:1545009462;}}}s:9:"user.name";s:[CENSORED]:"[CENSORED]";s:22:"twofactorauth.verified";i:0;s:12:"session.info";a:2:{s:2:"ts";i:1545008872;s:10:"remembered";b:1;}}

Initially I still couldn't login, because - as before - the login form set the new cookie only on the path '/' even though I was accessing /piwik/index.php. But I already had a '/piwik/' cookie from when I was logged in with 'files', so the Firefox presented the '/piwik/' cookie first in requests, and that was not a valid session in the database, so your code set a new cookie (again on '/') and asked me to login again....

After I manually removed my previous cookie on /piwik/ and reloaded /piwik/index.php it found that I was suddenly already logged in from the previous attempt.

To sum up: the pull request would work if you wished to force database usage (though some may still want files?), but you need to be careful because end-users might get caught in the trap above - especially because they would presumably be switching from file-based sessions that already have cookies set.

Note that the issue does not occur in a clean state but only after you sign out (should have tests?):

Load login page /piwik/index.php with no PIWIK_SESSION cookies:

• PIWIK_SESSION set on '/'

Login:

• PIWIK_SESSION set on '/' and subsequently many times on '/piwik/'
  [XHR calls not setting path? They are not HttpOnly and are also not Secure - is this Check that all Matomo cookies are set with the Secure flag in the UI #12841?]

Logout:

• PIWIK_SESSION on '/' deleted, but '/piwik/' remains

Login:

• PIWIK_SESSION set on '/' but it is overridden by the one on '/piwik/', which is now not logged in.
  [While the /piwik/ one is not Secure and not HttpOnly, neither of these stop it being valid here.]

Arguably the issue is "really" that path is not consistently set for cookies, either when set or when deleted. So when you log out it deletes the '/' cookie but there is a '/piwik/' one to replace it (since a path is not set and the file accessed is /piwik/index.php?...,) and that one isn't removed or replaced when you try to login - instead, only a '/' cookie is set, which is sent as well, but after the '/piwik/' one.

Another option: make sure you test all PIWIK_SESSION cookies; if one isn't logged in, try the next.
Or if both are needed for different things, and must be active at once, maybe name them differently?

In case it matters (almost certainly not for this), I also ran into a warning:

PHP Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /[censored]/piwik/vendor/tedivm/jshrink/src/JShrink/Minifier.php on line 243

This is the 'continue' after // check for some regex that breaks stuff

@GreenReaper can you test #13869? I believe it is the cause of cookie path change

Yes, it is. I changed that and flushed the file from the opcache. I still could not login, but once I'd removed the existing '/piwik/' cookie, I was able to login, and no more '/piwik/' cookies were created when accessing the dashboard. Subsequently I could logout, the '/' cookie was removed, and I could login again correctly.

So the clean state seems fixed, but you may have an issue with people who already have '/piwik/' cookies.
Then again, it probably wouldn't be any more of an issue than they already have... I think this might have been an issue for a while, I just never looked into it and just cleared out cookies, and it worked for a while.

@GreenReaper Updated the PR again this time to respect the login_cookie_path INI config option, which means in your case I think it'll switch the cookie path back to '/piwik/' (which is better, but apologies for for making you clear the cookies again).

Unfortunately I'm not too sure how to clear the cookies for users that would be affected by this since we'd have to know what the incorrect cookie path is and clear it once for every user. Would you have an idea @tsteur? Can't think of anything that would be simple to implement...

@diosmosis when the login_cookie_path is set, this might not be an issue anymore? If it otherwise uses the wrong session cookie, I assume the user simply won't be logged in and when logging in, the correct cookie will be set on the correct path? I presume we can't detect if the same session cookie is set in different paths and delete them if needed. Only thing I can think of is that when login_cookie_path != / then to maybe always delete the cookie for / (if that makes sense and is possible)

That would work, though seems a bit dirty to do that on every request. I suppose if this is the only reported case of this being an issue, perhaps a real edge case...

👍 to not do it for now

For what it's worth: I tried the additional change in the PR. I (still) only got '/' cookies (which works in a clean-field environment). That makes sense, since I was not using login_cookie_path. Presumably I wasn't doing any other way of indicating the path it was on (I don't know that I have anything specific in nginx to pass the path through), so previously in some cases the path was set to '/' and in others it was left default. The browser would know, of course, so if the path was not set it added '/piwik/' itself.

Once I set login_cookie_path, all cookies were on '/piwik/' instead. Indeed, this overrode [by being sent first] the previously-set '/' cookie even without removing it. Probably a good thing as login will work despite any such cookies, and it doesn't now send the piwik cookie with requests for the main website on '/'.