sso-server

sso-server copied to clipboard

We've started seeing the 'New session ID expected. Most likely cause: Cookies are disabled or bad provider.' error when logging in via mobile devices.

Is this due to Chrome disabling third-party cookies (https://www.cookiebot.com/en/google-third-party-cookies/) and SetCookieFixDomain being called without a value for the domain parameter (and hence the cookie not having a domain specified)?

Would it be relevant to incorporate SameSite=Lax on the cookie?

That sounds odd. If you dump the $_COOKIE superglobal from a test PHP script on an affected device that encounters the error, what cookie keys does the server see?

<?php
echo "<pre>";
var_dump($_COOKIE);

You have to have the sso_session_id cookie OR a sso_id request parameter to even access the frontend interface. The sso_id parameter is converted to a cookie for the duration of the session. sso_session_id2 is similarly created using a nearly identical function call. The only thing I can think of is perhaps the client device has "too many cookies" for the domain and refuses to accept new cookies.

Chrome can also be remotely debugged over a USB cable to access the network request log allowing you to see what the communication is between the client and the server, what cookies are being sent/received, what errors, if any, show up in the Console log.

This issue is only getting worse, although it's only seems to affect Chrome on mobile at the moment.

As requested, here's $_Cookie before throwing 'New session ID expected. Most likely cause: Cookies are disabled or bad provider.'

array ( 'sso_server_lastapp' => 'aH...==', 'sso_server_ns' => '8...Hg=', 'sso_server_id' => 'w...Rst-1...5', )

Some more logs from the last hour: [04-Nov-2022 09:54:54 Australia/Perth] New session ID expected. Most likely cause: Cookies are disabled or bad provider. array ( 'sso_server_id' => 's...b2-1...1', 'sso_server_lastapp' => 'a...w==', ) [04-Nov-2022 09:55:03 Australia/Perth] New session ID expected. Most likely cause: Cookies are disabled or bad provider. array ( 'sso_server_lastapp' => 'a...w==', 'sso_server_id' => 'r...Uh-1...3', ) [04-Nov-2022 10:39:54 Australia/Perth] The new session ID is already validated. array ( 'sso_server_id' => 'H...9', 'sso_server_lastapp' => 'a...=', 'sso_server_id2' => '0...3', ) [04-Nov-2022 10:41:27 Australia/Perth] The new session ID maps to a different session. Most likely cause: Bad provider. array ( 'sso_server_lastapp' => 'a...=', 'sso_server_id2' => '0...3', 'sso_server_id' => '3...2', )

Those are three different issues. The first three are not setting/accepting the sso_server_id2 cookie before the redirect. The fourth one involves someone revisiting the validation page after completing validation (e.g. using the browser back button). The fifth one is probably someone who started a new SSO server session and then went back to the validation page from a previous session.

Out of curiosity, do you have other cookies in $_COOKIE or just those three? How much data is in the cookies? If the user deletes cookies for your website, does it work?

After ensuring our code is unmodified (except for logging) and leaving it for a week - here are some logs from this morning. There are many more entries, so this is becoming a fairly major problem. I've shortened identifier strings, but you can see where they are the same.

[14-Nov-2022 10:05:11 Australia/Perth] New session ID expected. Most likely cause: Cookies are disabled or bad provider. array ( 'sso_server_lastapp' => 'aHR0cHM6LmF1Lw==', 'sso_server_id' => 'oK6MlhZm4ol3S-139125', ) [14-Nov-2022 10:05:13 Australia/Perth] New session ID expected. Most likely cause: Cookies are disabled or bad provider. array ( 'sso_server_lastapp' => 'aHR0cHM6LmF1Lw==', 'sso_server_id' => 'oK6MlhZm4ol3S-139125', ) [14-Nov-2022 10:05:25 Australia/Perth] New session ID expected. Most likely cause: Cookies are disabled or bad provider. array ( 'sso_server_lastapp' => 'aHR0cHM6LmF1Lw==', 'sso_server_id' => 'rV7sOkN-139126', ) [14-Nov-2022 10:05:27 Australia/Perth] New session ID expected. Most likely cause: Cookies are disabled or bad provider. array ( 'sso_server_lastapp' => 'aHR0cHM6LmF1Lw==', 'sso_server_id' => 'rV7sOkN-139126', ) [14-Nov-2022 10:16:19 Australia/Perth] New session ID expected. Most likely cause: Cookies are disabled or bad provider. array ( 'sso_server_lastapp' => 'aHR0cHM6LmF1Lw==', 'sso_server_id' => 'QO4FnzGz8i-139130', ) [14-Nov-2022 10:26:41 Australia/Perth] New session ID expected. Most likely cause: Cookies are disabled or bad provider. array ( 'sso_server_id' => 'SSUAXL3axJ-139140', 'sso_server_lastapp' => 'aHR0cHM6LmF1Lw==', ) [14-Nov-2022 10:26:49 Australia/Perth] New session ID expected. Most likely cause: Cookies are disabled or bad provider. array ( 'sso_server_id' => 'SSUAXL3axJ-139140', 'sso_server_lastapp' => 'aHR0cHM6LmF1Lw==', )

In answer to your questions: We don't use cookies for session data, and nothing has changed in this respect in the last five or so years. As far as I know, deleting cookies does work; restarting the browser doesn't.

Thanks :)

Another thought: How about PHP error/warning logs? If PHP is emitting headers BEFORE setting the cookie for whatever reason, then the cookie won't be set/sent.

Did you mean to close this issue?

Sorry, closed accidentally.

There are no other PHP errors being logged to file.

I'm yet to see this issue on desktop browsers; I'm concerned this may be a staggered release of a new behaviour in Chrome/WebKit.