Partial fix Problems with Google Authentication Not Working

[mattrogowski]

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.

Try on mobile - from personal experience I’ve only had it happen on mobile (both with XF and separate Laravel projects), and we had the issue on a forum as recently as yesterday. It’s certainly confusing though as it isn’t a case of it flat out doesn’t work ever, and I’m not really sure what determines whether it works or not.

 

[Mendalla]

I have been okay of late. I use only Google authentication on my work profile and haven't had a problem recently.

 

[digitalpoint]

Google authentication seems to work okay with Chrome 99 for me.

However, I still think it would be a good idea to set samesite explicitly within XenForo vs. rely on whatever browsers think should be the default (which sometimes changes between browser versions) or at least allow sites to set what they want samesite to be via a config setting (similar to secure). See: https://xenforo.com/community/threa...uthentication-not-working.202235/post-1559552

My particular use case is I have something built with XenForo that is intended to display inside an iframe (on a different site). Setting samesite to None allows users to stay logged in within that iframe. I've worked around it by extending XF\Http\Response::setCookieRaw(), so it's not a dealbreaker, but it would be nice (and what happens if future browser versions decide again to change what the default should be?).

The reasoning that browsers recently switched the default to samesite=lax is to protect against CSRF attacks on sites that are poorly designed. XenForo has robust CSRF protection at it's core, so the new default that is more restrictive serves no purpose in XenForo.

SameSite cookies - HTTP | MDN

The SameSite attribute of the Set-Cookie HTTP response header allows you to declare if your cookie should be restricted to a first-party or same-site context.

developer.mozilla.org

Note: Lax replaced None as the default value in order to ensure that users have reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks.

 

[Jeremy P]

I still think it would be a good idea to set samesite explicitly within XenForo vs. rely on whatever browsers think should be the default (which sometimes changes between browser versions) or at least allow sites to set what they want samesite to be via a config setting (similar to secure).

We actually did explicitly default to Lax at one point, but had to roll it back because of bugs in Safari/WebKit. I think we're unlikely to default to None given Lax shouldn't cause problems for conventional installations, but a config flag is probably reasonable for special cases like yours.

 

[digitalpoint]

We actually did explicitly default to Lax at one point, but had to roll it back because of bugs in Safari/WebKit. I think we're unlikely to default to None given Lax shouldn't cause problems for conventional installations, but a config flag is probably reasonable for special cases like yours.

Ya, I wasn't necessarily talking about defaulting it to None, rather just have a default that is set at the application level whatever that may be (so you don't need to worry about the future where browsers change what the default is). But ya, was just a thought off the time of my head... wasn't aware it caused the issues with Safari/WebKit, so... ignore. The ability for a site to set a default via $config was a different thing (and would be useful for me personally).

 

[XF Bug Bot]

Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.2.9).

Change log:

Make the default cookie same-site behavior configurable

There may be a delay before changes are rolled out to the XenForo Community.

 

[Jeremy P]

Try on mobile - from personal experience I’ve only had it happen on mobile (both with XF and separate Laravel projects), and we had the issue on a forum as recently as yesterday. It’s certainly confusing though as it isn’t a case of it flat out doesn’t work ever, and I’m not really sure what determines whether it works or not.

I haven't been able to reproduce this on iOS (which I don't think would be affected anyway since WebKit is the only game in town and they don't default to lax yet), nor on Android with the latest versions of Chrome and Firefox. I imagine this was a short-lived bug in some versions of Chrome, but if anyone can reliably reproduce this in the latest versions (Chrome 99.0.4844.73 or Firefox 98.2.0 at the time of writing), please let me know.

In the meantime, the default same-site behavior is now configurable by setting $config['cookie']['samesite']. We aren't setting any default value ourselves just yet, so it will still fall back to the browser default for now, but at least there is an escape hatch if you need it.