Page MenuHomePhabricator

Attempting to create a username with a hash in should throw an error
Closed, ResolvedPublic

Description

If you're on desktop with JS enabled and ignore the error-like warning [1] presented to you when you try to create a username with a hash in, everything including and after the hash is silently truncated from the username. This means the user ends up creating a username that is different from what they typed in, which is suboptimal from a product perspective.

It should simply not be possible to create such usernames, and there should be an error presented to the user if they try.

[1]: It's not actually an error, it's just styled exactly like one in the user interface, probably to disincline people from trying to create it.


Version: unspecified
Severity: minor
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=64959
https://bugzilla.wikimedia.org/show_bug.cgi?id=64409

Details

Reference
bz64960

Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:21 AM
bzimport set Reference to bz64960.
bzimport added a subscriber: Unknown Object (MLST).

(In reply to Dan Garry from comment #0)

This means the user ends up creating a username that is different
from what they typed in, which is suboptimal from a product perspective.

Truncation is just a part of username normalization. Some other parts including making the first character uppercase and replace underscores with spaces. There're still other cases where "the user ends up creating a username that is different from what they typed in".

And in practice, I saw some rename requests about 'I tried to create "foobar" but the system gave me "Foobar" but I still want "foobar".' and after rejection due to 'technical restrictions' they turn to say 'Then give me "FOOBAR" please'.

(In reply to Liangent from comment #1)

(In reply to Dan Garry from comment #0)

This means the user ends up creating a username that is different
from what they typed in, which is suboptimal from a product perspective.

Truncation is just a part of username normalization. Some other parts
including making the first character uppercase and replace underscores with
spaces. There're still other cases where "the user ends up creating a
username that is different from what they typed in".

These other cases you mentioned are a bit different though: trying to log in with the username you typed in (e.g. "dGarry (WMF)" rather than "DGarry_(WMF)") will still work, as will typing any of these variants as a URL to find the person's userpage. Neither of these are true of the username containing the hashes.

The case with the hash is the low-hanging fruit; it's one bit where the user experience is particularly confusing, and there is a clear solution for fixing it.

Well using a user name with extra #foobar works in wikilinks and URL: #foobar is just considered page fragment.

I guess it's the just the cause of this bug that "#" starts a fragment: they use class Title to normalize user names and #foobar is split out after being parsed.

Possible caused by gerrit 115329 where a Title call was added

(In reply to Liangent from comment #1)

And in practice, I saw some rename requests about 'I tried to create
"foobar" but the system gave me "Foobar" but I still want "foobar".' and
after rejection due to 'technical restrictions' they turn to say 'Then give
me "FOOBAR" please'.

This is bug 61416 and the associated patch If60219a1 which needs love.

(In reply to Umherirrender from comment #4)

Possible caused by Gerrit change #115329 where a Title call was added

Ugh, sounds likely. We should probably check the the object returned by Title::makeTitleSafe() is in the User: namespace and has no interwiki or fragment parts. (We should also probably make this a separate methods and add tests.)

(In reply to Bartosz Dziewoński from comment #6)

(In reply to Umherirrender from comment #4)

Possible caused by Gerrit change #115329 where a Title call was added

Ugh, sounds likely. We should probably check the the object returned by
Title::makeTitleSafe() is in the User: namespace and has no interwiki or
fragment parts. (We should also probably make this a separate methods and
add tests.)

I am not sure, but that sounds like User::getCanonicalName (which also handles the # part), which gets called by User::newFromName, but due to gerrit 115329 there seems a problem with that, but I cannot see the problem at the moment.

Title::makeTitleSafe here will you give always a title in User namespace and without a interwiki or null, if that is not possible. By using Title::newFromText you have to check that, because there the given title can override the default namespace. With makeTitleSafe it should be impossible to do that.

User::getCanonicalName( …, 'creatable' ) (or User::isCreatableName( … ) that calls internally) is very strict and will reject, for example, a username like "User " (with a *trailing space*).

Actually, we can't even check for the fragment reliably, because "User:Foo#" (trailing hash sign) will be considered as having no fragment part.

I say we just explicitly check for a '#' in text there and call it a day.
I'm afraid to change the behavior of User::getCanonicalName() unless somebody
who knows more about how these things work verifies whatever I'd write.

(In reply to Umherirrender from comment #7)

Title::makeTitleSafe here will you give always a title in User namespace and
without a interwiki or null, if that is not possible. By using
Title::newFromText you have to check that, because there the given title can
override the default namespace. With makeTitleSafe it should be impossible
to do that.

Yeah, you're right of course.

Change 132584 had a related patch set uploaded by Bartosz Dziewoński:
SpecialUserlogin: Error out when attempting to create a username with a '#'

https://gerrit.wikimedia.org/r/132584

Thanks for working on this Bartosz! I'll try to get an engineer to review your patch.

Change 132584 merged by Brion VIBBER:
SpecialUserlogin: Error out when attempting to create a username with a '#'

https://gerrit.wikimedia.org/r/132584

I guess this should be fixed now. I'm not happy with the solution, though :(