User pfaffman reports a sudden failure of Google OAuth authentication across multiple Discourse sites after running upgrades, despite identical credentials and configurations previously working. The error logs show “Authentication failure! authenticity_error: OmniAuth::AuthenticityError, Forbidden” and later “Attack prevented by OmniAuth::AuthenticityTokenProtection” pfaffman. After temporary fixes via rebuilds, the issue reappeared following a container restart and plugin edit pfaffman. supermathie identifies the root cause: pfaffman inadvertently upgraded omniauth from the Discourse-locked version 1.9.2 to 2.1.2 during a bundle install triggered by installing tiny_tds for data imports — a change that makes the setup unsupported. pfaffman confirms this was likely caused by deleting Gemfile.lock and running bundle install without IMPORT=1, which normally preserves dependency versions. The issue appears to stem from incompatibility between OmniAuth 2.1.2 and Discourse’s authentication flow, possibly due to changed parameters or missing settings. supermathie advises restoring from a backup after imports to avoid unsupported gem upgrades. The case highlights the importance of using IMPORT=1 to maintain version stability during plugin or gem installations.
I think this is a bug, but I don’t understand how I could be the first one to complain and Google auths work on Meta. . .
I have several sites that use Google auth set in ENV variables in the YML file. They’ve worked for years. One stopped working today, but two others still worked. I ran upgrades on those sites and now they all return this message:
Sorry, there was an error authorizing your account. Please try again.
When the first one stopped working, I thought it might be an issue on the Google side, but the correct URLs are still there.
EDIT: Well, the logs say “(google_oauth2) Authentication failure! authenticity_error: OmniAuth::AuthenticityError, Forbidden” so that sounds like Google doesn’t like my credentials.
These are the same credentials that the other sites are using and that these sites were using before the last upgrade. I see that the expected values are in /var/www/discourse/config/discourse.conf and in SiteSettings in Rails.
And then I upgraded the other site and it too is working. I see nothing in the commits or my stuff that could explain any of this. Usually I can at least prove that I am the cause of the problem.
Sigh. And now nothing has changed and what worked yesterday afternoon when I “fixed” it by rebuilding both sites is now giving
Sorry, there was an error authorizing your account. Please try again.
for both of them.
The thing that did change is that I entered both containers and edited /var/www/discourse/plugins/discourse-data-explorer/plugins.rb and did an sv restart unicorn.
So could somehow restarting the unicorn cause a problem? That makes no sense. I don’t want to restart the containers because both are doing long-running imports for the next 30-40 hours.
I did an apt update to install some stuff (vim but especially tiny_tds for the import. So maybe something that I upgraded forced am upgrade of omniauth.
No. That’s not it. I removed the Gemfile.lock so when i did the bundle install, it upgraded omniauth?
So maybe rather then this being an annoyance, it might really help find an issue with the new omniauth.
I’ll see it I can replicate it, maybe by just upgrading omniauth. Maybe just delete the Gemfile lock and bundling?
Oh. Maybe this is why setting IMPORT=1 is more important than I thought.
Edit: yes. It definitely must be about doing a bundle install to add the tiny_tds for the import. I often don’t use IMPORT=1 because it causes other problems. I’ll try to confirm that it’s the Omni auth upgrade that’s causing the problem, but it seems very likely
Soon as you did, this whole thing became unsupported. Major gem version upgrades are something that needs to be tested, I’m not surprised you’re having problems.
(as I understand it) When we do imports we do what’s necessary to get the data in place, then we take a backup and restore it to a clean site.
I’m not quite sure how to get the tiny tds installed without bumping the version (perhaps the IMPORT=1 will do it), but at least I now have an explanation. And this explains why building a new container fixes it.
Thanks so much for noticing that. I was going crazy.
Maybe the be version has different parameters or something so it’s just not getting the settings at all.
