We cannot detect if your account was created, please ensure you have cookies enabled

Hello Community!

Today I was informed that people can’t create a new account on our discourse page (https://answerhub.lightact-systems.com), because no matter which login option they choose (username/pass, FB, Google, Twitter), they get the following message.

We cannot detect if your account was created, please ensure you have cookies enabled.

I read on another thread that I should make sure that I have “enable local logins via email” setting checked and I do.

Does anyone have any ideas on what I can do?


1 Like

To follow up with some of my findings…

I’ve been able to create new user accounts using either browsers devices that I haven’t used before at all. For example, Chrome works only if I disable Syncing or if I am using Incognito mode.

If someone can let me know how to fix this, that would be awesome.


Sounds like you have unusual browser config or plugins. Try in safe mode with plugins disabled, or use a different browser with default settings.


How did you install? Do you have a reverse proxy that might be interfering?


I don’t even know what ‘reverse proxy’ is. :slight_smile:

I installed it on a Digital Ocean droplet with a standard procedure described somewhere on these forums.

It’s quite possible that it is something like that but on my 2 PCs, it happens on both Chrome (that I regularly use and has lots of extensions and stuff) and on Edge (that I use only for debugging and similar things). Actually, I heard about this from our client from Berlin, who also reported this, so it might not be so unusual after all.

Thanks for your suggestions.

p.s. I’m not sure if that’s too much to ask, but would you guys try to login using Chrome, for example and tell me if it works?

I got logged in on my phone. Browser plugins seem like the most likely culprit.


I’m getting this message with Chrome:

But Safari correctly responds with:

Except I wouldn’t think it would say an existing email address was good while typing it in and then reject is after pressing ‘Create New Account’.

Looks to me like you have cookies disabled for your discourse site in chrome using some sort of extension.


You are correct. It’s some Chrome extension.

1 Like

Users are having the same problem on a forum I’ve created, and I have personally encountered the issue. Removed every Chrome extension from the browser, but the issue has also surfaced on other browsers. It seems incognito mode helps in 90% of the cases but even going that way is not certain to work.

A week ago I tried to create an account here, to further the discussion and was met with the following:


However, I was able to create the account today without any issues -same browser (Chrome).

Any new idea what can be the cause for this?

Telling new users they have to use incognito or try other browsers if the account creation failed just doesn’t seem like a great option.

1 Like

I can’t repro this in Chrome. Perhaps there is something on your network, router, or in your local “anti-virus” software that is interfering.


tl;dr Discourse thinks Chrome is a spambot

We also encountered this issue and think we know what’s causing it.
(Major thanks here to @RGJ for some impressive detective work)

  1. The Discourse signup form contains a field called password_confirmation; this is a hidden field, meant to trip up spammers.
  2. Chrome pre-fills passwords for known domains, it promptly fills in password_confirmation
  3. Discourse sees a value it doesn’t expect in its honeypot and denies access

So yeah, difficult issue to track down, since

  • clean installs don’t have the behaviour (since no password is stored)
  • incognito mode doesn’t have the behaviour (since it doesn’t pre-fill values)
  • inspector looks normal (since you expect a password field to be filled)
  • other browser don’t trigger it
  • not all users will have passwords saved
  • there doesn’t seem to be a setting to disable the honeypot
  • the error message is (probably deliberately) extremely vague

Seems clear that the culprit is Chrome itself. That said, with that browser having major marketshare, it might be good for Discourse to roll with the punches and create a workaround/fix?


No such feature exists for signup user “spam” prevention. While it is an interesting theory, it has no basis in reality. Sorry.

If the account is not created, this is usually due to oddball “privacy” plugins the user has active in my experience. Try in a different clean browser install with no modifications, customizations, or plugins.

1 Like


I’m talking about this field:

Generated by this piece of code:

Validated by this controller:

Which is also present when I inspect Meta, in Safari


I’ll just keep repeating this until you hear me:

See above text. There is no broken “spam” user account check. There are only broken browser configurations created by users. If you can repro in a clean browser, no plugins, no add-ins, no browser setting changes, let us know.


WOW, that is quite a statement.

Give me a repro in Chrome. I run totally stock. I’ll be waiting here for your repro steps.

I had a guy reporting the same issue ( We cannot detect if your account was created…). I suggested using incognito mode and that worked for them. They also said that they had a bunch of plugins in their browser, which was likely the problem as I haven’t had anyone else complain about not being able to register.


I believe one example plugin known to cause this is Privacy Badger. It’s best to report the issues to the people who make the plugins, so they can fix the plugins.

1 Like

Discourse shouldn’t need to support or differentiate between browser plugins altering the page, and malicious code creating spam users.

If you insist on using something which interferes with the page, you accept any undesirable consequences which come along with it. Convenience isn’t a defence for asking for more work be done, not does it constitute a bug.

1 Like