Two PHPSESSID cookies

[crecent77]

We are having an issue with two PHPSESSID cookies being created or a previously existing PHPSESSID cookie not being cleared after we implement php-auth.

$auth->check() passes at login but subsequently fails if we do not clear one of the cookies.

This seems to be happening in two circumstances:

1. If a user has not cleared an existing PHPSESSID cookie, created before we implemented php-auth. This may be the result of the user having the website open when we updated the code to include php-auth.
2. If a user has a domain and subdomain open in the same browser. If we have something like abw.mywebsite.com and mywebsite.com open in the same browser then we see two PHPSESSID cookies .abw.mywebsite.com and .mywebsite.com.

$auth->check() passes at login but subsequently fails if we do not clear one of the cookies.

Any ideas on what the issue / solution may be?

[crecent77]

It looks like this is the same issue as detailed in closed Issue #29.

[ocram]

Thank you!

Can you share the browser (name and version) that you're testing this in? Cookie handling is often specific to individual browsers.

The fact that $auth->check() passes at login is because that doesn't involve cookies at all. So we can safely ignore that case. So let's see if we can find out what's wrong with the cookie handling.

The first case might be due to different cookie settings, e.g. the Secure flag, the HttpOnly flag, etc. Can you check this? It's strange, by the way, that the old cookie is not picked up at first (which requires a new cookie to be set) but then the old cookie blocks the new cookie from working. Perhaps this is a browser-specific bug. Or a PHP bug. Or really something that we must fix in this library. We'll see. A simple solution may just be using a different session cookie for this library, either by calling \session_name('MYSESSID') before creating the instance of this library, or by setting session.name to a different value in php.ini. Would those solutions be acceptable to you?

The second case is definitely related to the other issue that you referenced. Can you try the steps that I suggested there for us to be able to re-produce this behavior? Thanks!

[acodispo]

Hi @ocram, I'm involved in dealing with this issue, too.

We've noticed this issue definitely on Chromium (Version 59.0.3071.109 (Developer Build) Built on Ubuntu , running on Ubuntu 16.10 (64-bit)), and I'm pretty sure that @crecent77 has seen it on Firefox as well.

I've actually refrained from clearing my cookies in one particular browser session so I can test this problem. The "old" cookie (pre-php-auth) is much like this:

Name: PHPSESSID
Domain: example.com
Path: /
Send for: Any kind of connection
Expires: When the browsing session ends

The new cookie (I believe created by php-auth) is:

Name: PHPSESSID
Domain: .example.com
Path: /
Send for: Same-site connections only
Expires: When the browsing session ends

It is domain and send for that differ.

I don't think that using a different session.name would be a problem, but I will have to check.

We will attempt to reproduce the other error for you as well.

Thanks for your help!

[acodispo]

I left a comment on #29. I was able to duplicate, but had to modify your described process slightly. See the comment for details.

[ocram]

Thank you!

The explanation and the possible solution that I suggested in #29 do probably affect your second problem described at the top, right? Though I'm not sure about the first problem.

[ocram]

The first problem is definitely caused by individual cookie attributes that don’t match between the old and the new cookies, and you have found those bad attributes already.

The second problem is because this library does not work on subdomains other than www without setting the desired cookie domain. This is explained and tracked in #29.

[ocram]

This has finally been fixed: #29

Thank you for your help!