Partial fix Problems with Google Authentication Not Working

robdog

robdog

Well-known member
Affected version
2.2.8
For some reason, Google Authentication through Chrome is broken. I have a number of users who cannot log in through Chrome on desktop or Chromebooks. I am not able to log into XenForo through Chrome as well with my connected account. When I try to authenticate, it will simply send me right back to the auth screen.

Chrome Version: 97.0.4692.71 (Official Build) (x86_64)
 
Last edited:
One thing to note is that when I auth through Chrome, the session cookie value does not match a session in the DB. For FireFix and Safari, it works fine, there is a matching session in the DB.
 
Just signed in here with it but I'm on Edge Chromium, not Chrome itself. Won't be able to test on Chrome until later.

EDIT: Worked on my site as well.
 
Mendalla said:
Just signed in here with it but I'm on Edge Chromium, not Chrome itself. Won't be able to test on Chrome until later.

EDIT: Worked on my site as well.
Click to expand...
Thanks for checking. I will check Edge Chromium, but let me know if you are able to log in with regular Chrome. Also, this does work fine on FireFox and Safari, but fails in Chrome.
 
Yep, when I try to login either here or my site with Chrome (version 97.0.4692.71 per Help - About) using Google it just takes me back to the guest view. Interesting. Also forced me to reset my password here so I could log in to respond. I've been logging in with Google here normally so forgot my site password. :oops:
 
Mendalla said:
Yep, when I try to login either here or my site with Chrome (version 97.0.4692.71 per Help - About) using Google it just takes me back to the guest view. Interesting. Also forced me to reset my password here so I could log in to respond. I've been logging in with Google here normally so forgot my site password. :oops:
Click to expand...
Okay, phew. Bad that the bug exists, but glad I am not crazy, lol.
 
@Chris D, okay I figured out the issue.

The issue stems from leaving the cookie value SameSite empty. If the SameSite value is empty it is going to default to 'Lax'. You can read all about it here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite

Because this is getting set to 'Lax', it's causing the problem that I am describing above. The work around is to force it to a value of 'None'. Inserting random StackOver link: https://stackoverflow.com/questions...tting-from-office-365-oauth-callback/70661197

So where did I hax... I mean fix it(lol).

/public/src/XF/Http/Response.php in the setCookie function on line 330. I added this code to that function:
PHP: 
        // @HACK: This is to fix a cookie issue with Chrome 97+. The SameSite flag
        // is defaulting to 'Lax', which is causing a problem with cookies being
        // set properly. Since this is modifying a core file, it will need to fixed
        // each release until this is brought into core.
        if (\XF::config()['production']) {
            $sameSite = 'None';
        }

I had to add this "production" check because setting the SameSite to 'None' requires a secure environment, and my development environment is not secure. I have this hacked in, but this would be great if we could get it into core some how. This is only affect Chrome 97+, but I have a feeling that will continue to grow as more people upgrade their browsers.
 
There does seem to be an issue with connected accounts in general, seemingly after a recent Chrome update. I can't use Twitter to log in in Chrome but can in Firefox. We had a support ticket for our connected account provider addon (which only adds new providers) but it seems to affect core XF.

Ticket we had mentioned changes to headers:

Firefox and old Chrome: [HTTP_SEC_FETCH_SITE] => same-origin [HTTP_SEC_FETCH_MODE] => same-origin [HTTP_SEC_FETCH_DEST] => empty
New Chrome: [HTTP_SEC_FETCH_DEST] => empty [HTTP_SEC_FETCH_MODE] => navigate [HTTP_SEC_FETCH_SITE] => cross-site

I had a similar issue on an unrelated Laravel project recently so it seems something in Chrome has changed here.
 
Can confirm, we have been debugging this problem on my site for the past 9 days. We just discovered this new Chrome 97 issue and were able to confirm it's the cause of our problem.

They've done the same thing with Firefox 96:
1642214431060.png

This was a really annoying bug to track down.

We force users to pay using Paypal during registration and when paypal redirects them back to the main site to complete registration, the cookie is not being set because Chrome 97 is blocking the cookie as a CSRF attack.
 
Last edited:
Hi!
we've got the same problem with the brave browser which updated to the chrome 97. engine for their last update.

We have observed the same as mattrogowski:

Firefox and old Chrome:
[HTTP_SEC_FETCH_SITE] => same-origin
[HTTP_SEC_FETCH_MODE] => same-origin
[HTTP_SEC_FETCH_DEST] => empty

new version:

[HTTP_SEC_FETCH_DEST] => empty
[HTTP_SEC_FETCH_MODE] => navigate
[HTTP_SEC_FETCH_SITE] => cross-site

Chrome seems to set a new default if the value is empty from the server.

Regards, Ingo
 
Okay, now Edge seems to be doing it, too. Just tried it again. Makes sense since Edge is also using Chromium and is on 97 but I swear it was working yesterday.
 
Having the same issue with our site as well, would love to see an official response to this 👍

Just a note, having issues with connected accounts in general, not just Google.
 
Last edited:
Ran into this for something else, but the root cause was the same (needing to set $sameSite = 'None';)

I was able to work around it by making my own Response class, then overriding the default one in the config.php file:

PHP: 
class Response extends \XF\Http\Response
{
   public function setCookieRaw($name, $value = '', $lifetime = 0, $path = '/', $domain = '', $secure = false, $httpOnly = true, $sameSite = null)
   {
      if ($sameSite === null)
      {
         $sameSite = 'None';
      }
      return parent::setCookieRaw($name, $value, $lifetime, $path, $domain, $secure, $httpOnly, $sameSite);
   }
}

A cleaner way to do it would be to support $sameSite as a config option similar to how $secure is.

PHP: 
public function setCookie($name, $value, $lifetime = 0, $secure = null, $httpOnly = true, $sameSite = null)
{
   $cookieConfig = $this->cookieConfig;

   $path = $cookieConfig['path'];
   $domain = $cookieConfig['domain'];
   $name = $cookieConfig['prefix'] . $name;

   if ($secure === null)
   {
      $secure = $cookieConfig['secure'];
   }

   if ($sameSite === null)
   {
      $sameSite = $cookieConfig['sameSite'];
   }

   return $this->setCookieRaw($name, $value, $lifetime, $path, $domain, $secure, $httpOnly, $sameSite);
}

Not sure what the ramifications of setting $sameSite = 'None'; as the default for everyone, but maybe it's necessary to retain the existing functionality of connected accounts?
 
Are you guys still experiencing this? I can't reproduce it locally or here on this site with Chrome 99. I think lax cookies should still be visible for top-level cross-site redirects so long as they are GET requests, if I'm reading the spec right.
 

Similar threads

RG70Hz
  • Question Question
XF 1.2 SMTP Mail Server Not Working Properly
2
Replies
25
Views
3K
RG70Hz
RG70Hz
bplein
Not a bug Automated bounced and unsubscribe email handler errors - authorization problems (cross post from community forums)
Replies
2
Views
822
bplein
bplein
Nicky Vermeersch
  • Question Question
XF 2.1 Error on mailing
Replies
1
Views
598
Nicky Vermeersch
Nicky Vermeersch
Nulumia
Add-on A Look At The Upcoming Public Release of SEO & Index Tools
2 3
Replies
46
Views
10K
Forsaken
Forsaken
Jessiray
  • Question Question
XF 2.2 Activation Emails Not Being Sent
Replies
14
Views
3K
Jessiray
Jessiray
Top Bottom