Username not detected (login failing) if username contains special caracters

[moving-bits]

Reported by user on support (ticket 155297):

User cannot login. Possible cause is a double quote contained in the username. This translates to \" in the source (multiple times in that specific case, as the username is similar to xyz"abc").

At least search pattern PATTERN_LOGIN_NAME_CACHE_COUNT needs to be adapted, as it currently greps chars until it reaches the first ".

Reported for version 2024.04.13

[Lineflyer]

Another user on support, but slightly different.
Login is OK but username on homescreen is shown wrong.

Username is like: Max&Moritz
Shown in c:geo: Max\u226Moritz

Version: 2024.04.13
support ticket: 289622

[Lineflyer]

More results from this user, which seem to show that username detection works in some parts of c:geo but not for the initial login.
Adapted username for privacy reasons.

1. Settings/Services login and password = ok
2. Home = Test/u226World
3. I made a log (Will Wait)
4. return Home = Test&World

Another test:

1. Settings/Services login and password = ok
2. Home = Test/u226World
3. Refresh a geocache from a list
4. return Home = Test&World

[moving-bits]

Info from the affected user: JS source for the relevant prt is \u0026, which is a JS-encoding for the &-sign.

[moving-bits]

BTW: Is there any reason why we try to detect the username during login? We have the username in the credentials, and users should not login using an email address anyway (for gc.com at least).
If we do need to update the username we could try to get it using serverparameters, which is JSON formatted and might spare us regexp parsing for encoded Unicode characters (haven't checked).

[eddiemuc]

BTW: Is there any reason why we try to detect the username during login? We have the username in the credentials, and users should not login using an email address anyway (for gc.com at least). If we do need to update the username we could try to get it using serverparameters, which is JSON formatted and might spare us regexp parsing for encoded Unicode characters (haven't checked).

Wrt parsing part: the key here is of course not to apply regex expressions on json snippets but to use the whole json and parse it using JSON lib. Then such conversions are done for us.

Why the username is parsed from page and not from serverparameters I don't know. Probably it simply "has been this way forever"...?

[moving-bits]

I can try to look further into it, but won't be able to do so before tomorrow evening.

[moving-bits]

PR #15653 attempts to fix both issues:

• double quotes in user name terminates username detection
• JS-encoded Unicide characters in username

Switching to using serverParameters did not seem to be feasible as username detection is called multiple times before serverParameters get retrieved.

[Lineflyer]

User on ticket 155297 (initial issue) reported back, that the fix is working.

[moving-bits]

The second affected user (different special characters in username) confirmed fix as working as well, so let's close here for now.