Unicode (Russian) username validation fails randomly

Usernames with Russian characters, e.g. фыв (not sure if depends on specific characters) sometimes fail validation.

Tested in latest Chrome and Firefox on Ubuntu 19.10, Discourse version is 2.4.0.beta8 (16de46f8d4).

The HTTP request seems to be always the same for these 3 characters, reproduced by repeating multiple times in DevTools Console:

fetch('/u/check_username?username=%D1%84%D1%8B%D0%B2&email=', {headers: {'X-Requested-With': 'XMLHttpRequest'}}).then(r => r.json()).then(console.log)

Tried to set the unicode whitelist [йцукенгшщзхъфывапролджэячсмитьбюЙЦУКЕНГШЩЗХЪФЫВАПРОЛДЖЭЯЧСМИТЬБЮёЁ], no effect.

@gerhard any idea what is going on here? Is our Russian regex incorrect?

I can’t reproduce the issue. Any chance that you entered some kind of invisible whitespace or something like that when it showed you the “must only include numbers, letters, dashes, dots, and underscores” error message?

The username check runs on the server, so if there was a problem with the regex, it should always generate the same results for the same input.


Yes, that’s why it’s strange.

I thought that it could be related to some kind of rate limiting, but now I got the error even after a long pause (2 minutes) on the first request, and then success on the third request in several seconds.

I can reproduce it executing the code above in DevTools.

I’m still not able to reproduce the issue. Could you please try to disable and reenable the unicode usernames site setting? Maybe a unicorn worker didn’t get the memo that the setting changed. That would explain why only some of the requests result in an error. If that doesn’t help, try rebuilding the app container.


It didn’t help, but yes, I cannot reproduce it too in my local Docker instance and looks like it disappeared after restart when upgrading Discourse.

btw if anyone is looking for a simpler way to whitelist Russian letters, looks like this regex works: [\p{Cyrillic}]

1 Like