Last modified: 2014-05-18 14:30:08 UTC
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.
(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 change #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 change #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 :(
Thanks for the patch MatmaRex!
