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.
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.
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?
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.
We also encountered this issue and think we know what’s causing it.
(Major thanks here to @RGJ for some impressive detective work)
The Discourse signup form contains a field called password_confirmation; this is a hidden field, meant to trip up spammers.
Chrome pre-fills passwords for known domains, it promptly fills in password_confirmation
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.
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.
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.
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.
