Session cookies disappearing from Chrome with PHP / Apache server
Update: It looks like an issue that started a few days ago was due to improper handling of the "safe" cookie flag. We still haven't resolved the issue started on Feb 1st.
I am running an internal PHP / Apache site where I work. On February 1, we began to receive reports of employees leaving it randomly several times a day. We haven't changed the authentication code for years, but we noticed that Chrome received a significant update that day: https://chromereleases.googleblog.com/2017/02/stable-channel-update-for-desktop.html .
The problem has gotten worse in the past few days and Chrome did not store session cookies at all for some users. After navigating to the site, the server tries to set a cookie and the employee is redirected to Google for authorization, and then when they return to the site their cookie is gone.
I have reproduced the problem with minimal code in this simple php file:
<?php
session_set_cookie_params(60 * 60 * 24 * 7, '/', '.corp.company.com', false, true);
session_name('CompanySessionID');
session_start();
$_SESSION['UserName'] = 'test';
When the affected employee visits the page, the set cookie header goes through as expected, but Chrome does not store the cookie.
Additional Information:
- I've tried all suggestions for PHP session after redirect
- Initially, the problem did not affect incognito mode, but since a few days ago, it
- Clearing cache / cookies never helped.
- Reinstalling Chrome previously fixed the issue for about a week.
- The problem is missing in Firefox or Safari
- Not all employees are affected.
- All employees use OS X
- Changing the session name from
CompanySessionID
toCompanySession
fixes the problem for a subset of users and breaks it down into a different subset of users - Sessions still exist on the server, they are just cookies missing from the browser.
- Using a proxy to view the requests, I can see that there are no headers that should remove the cookie.
- We are using PHP 5.4.24
How can I find the source of this problem? Should I be logging a bug with Chrome?
source to share
I figured out a more recent question using @cmorrissey. We recently rolled out HTTPS to the server, and when people received new cookies over HTTPS, they would get the security flag set.
After that, the cookie will no longer be sent on requests over HTTP (as expected). However, what was unexpected was that Chrome would also prevent the server from setting an insecure session cookie of the same name, since it already exists. This is why the PHP file example shown in the question couldn't set a cookie at all unless the session name changed.
source to share