This is great info. I haven’t seen CORS issue specifically, but I’ll dig more on this. If I find anything I’ll post it here.
After seeing the scripts looks like is related to Cloudflare, are you using Cloudflare? https://boards.neocron.org/cdn-cgi/apps/head/QNWX_8GN-3K7wUr6Qa73LdoD3JI.js. We are not using that so probably we haven’t seen this specific issue.
Thanks!
Digging into it, we had Settings->Security->content security policy enabled.
Once we disabled that, users were able to register. We tried adding the URLs found in that report above to the whitelisted script sources but it would not solve the issue.
Chrome apparently has beefed up their CSP. -> Content Security Policy (CSP) - Google Chrome
mmm I’m afraid we have that disabled, it should be another thing for us causing this issue
Apologies 
We have DISCOURSE_ENABLE_CORS set to true, and we have our cors origins set to the following… 
Don’t know if any of that could help you or might be different than your setup?
We have the CORS flag enable too, but not sure if this is related.
This is a CSP problem, not CORS.
Is this a subfolder setup?
EDIT: having come back around and looked at this again, I see what’s going on.
I can confirm this was injected by CF.
We STRONGLY recommend against disabling CSP on a production site. Instead, turn off Cloudflare if possible (we have had MANY, MANY support cases about CF negatively affecting Discourse’s JS) or at least disable all Cloudflare optimizations.
This opens massive security holes on your site. We STRONGLY RECOMMEND that you DO NOT do that. It’s very bad advice.
Hey @supermathie,
We don’t use Cloudflare and we are seeing this issue now with 2 users. The workaround we are giving them is to use incognito or another browser but maybe there are more users that are not reporting this issue to us.
Our community is mostly non-tech people, so I don’t think they have weird browser setups.
Can you provide more info on what’s triggering this issue? maybe I can go from there to find a solution.
Thanks!
I wish we knew exactly.
There’s a hidden input field on the “Account Creation” screen that is checked for integrity at account creation time.
If this field is tampered with, the account creation fails.
Can you please ask your users to disable their plugins one-by-one until they locate the culprit?
We also have a ticket open with the Chrome project to investigate this behaviour.
Let me remind you of this screenshot from a non-technical user’s computer:
You can’t assume anything 
Yeah I mean is not 2000 anymore, browser security and malware prevention are better now (I believe). Another user reported this today, I’ll try to get more info from them and hopefully find something.
Thanks!
Fantastic. We really want to nail this down so let us know.
I’ve got a friend experiencing this problem too - I’m trying to bring him on as a moderator. When I sign up on an incognito window, it works fine, but he can’t even in an incognito window. So I’m confident it’s not a problem with my install (I’m using plugins with my Discourse, but only official ones) but with his browser somewhere.
I’m working with him to pin down the problem, but if it’s not a plugin problem, I’m wondering if there’s something with our Chrome versions - whether something’s going on under the browser hood I’m unaware of, but I can’t say for sure yet. Currently trying to get hold of his version number for comparison but he’s Californian and so if he’s sensible, he’s asleep 
OK, not sensible, but he’s awake and informative. He updated from 75.0.3770.142 to 76.0.3808.87 (64 bit), which did not help on its own in the main window, but after clearing cache and cookies, he was able to sign up on an incognito window. He’s using an entirely vanilla Chrome set-up aside from Adblocker.
EDIT: I couldn’t tell you if clearing cache or cookies would work on 75.0.3770.142 without being able to repro it (I can’t), but I do find it interesting that it did at least seem to help my friend.
Hello, I just setup a fresh instance today at community.boid.com and came across this error message after trying to register a second account (both inside my normal chrome window as well as incognito). I was able to resolve the issue by manually deleting the autofill passwords from my google account and not using any of the auto-fill options on the signup form. I noticed that Chrome was suggesting many different authentication options for autofill from other unrelated websites. I haven’t seen this behavior on other sites so just wanted to mention my experience.
As far as I can tell, this does seem to be related to google chrome autofill.
I have one way to repro this, but it’s obtuse. You’ll need two browser windows.
Load your site in incognito mode, bring up the “create new user” dialog.
In a second browser window, log in as admin. Go to the site settings. Enable “invite only”, which disables public registration.
In the incognito browser, attempt to complete signup as the new user via that create new user dialog you brought up earlier.
You won’t be able to, because new user creation is no longer allowed, so you’ll see… our old pal…
At least we have that repro, though it is … insane. 
I’ve never, ever been able to repro this in any other way, nor has anyone in this topic ever been able to provide a set of repro steps on a default instance of Chrome with no plugins. If you can, please step right up and provide those repro steps…
I reproduced this error on try.discourse.org:
OK, very good, that’s a repro we can work with, thanks for that.
However, note that it still takes manual user action – right click in the password field at new account creation / sign up and press “suggest”. I have to f5 refresh the page before initiating the signup dialog to get this to appear reliably, but then it does.
Now that we have a kind of repro @sam maybe we can assign the work?
We have 2 mechanisms in play for stopping bots from registering accounts blindly.
We pretend to have a “password confirm” field which is in fact a “trick”, we expect it to be a very specific value. It is an INPUT box that is not rendered on the screen, it is in a hidden div.
We have a challenge string that we expect the JavaScript to process and echo back.
If either (1) or (2) don’t happen right then we treat the request as suspicious and do not register an account.
What the Chrome password manager is doing is “filling in” the password in the new-account-confirm field:
{{input type="password" value=accountPasswordConfirm id="new-account-confirmation" autocomplete="new-password"}}
This INPUT is hidden and not rendered on the screen.
We have 2 alternatives here.
Remove this protection and just treat it as a fact of life that password managers mess up here. They do not bother checking a “confirm password” field is actually visible prior to filling it up.
Ask Chrome team to stop doing this, filling in information in INPUTs that are not visible is not nice. (I did that)
I don’t know … I guess we can go with (1) it is an easy change. I could remove the protection and make the JS client calculate a hash bitcoin style to prove it is around doing work. For example I give the client a string and tell it to append numbers to it until the md5 ends with 00 at least it will be punishing to bots and ultra cheap to confirm on the server.
Getting bots to blindly compute MD5s, I guess, is one way of getting them to literally pay the bills and fund my Bahamas retirement .
Is it possible to completely disable such a mechanism and enable the good old Google CAPTCHA? I think this will maintain security and, at the same time, allow more users to register.
Or we can wait for the your hotfix. Which option seems best to you? We launch a large stream of our partners at our forum at the beginning of next week.
I’ve just created a new account, with ZERO anti-spam / spyware / software on the browser and I encountered the same problem. I solved it by using the ‘log in with google’ method and it worked after that.
