and still have it return a proper HTML document that covers that user's profile page. Hell, the username could be some insane zalgo-tier shit and still function properly.
I see some comments defending arbitrary "bandaid" architecture and I think that this is not defensible for something the scale of GitLab. This is basic HTTP stuff.
This reasoning is wrong to me. I see this very much as a problem with using usernames to refer to repositories in the first place, not with username reuse. For heaven's sake, let me just refer to a repo by a unique ID of its own. There's no reason for the username to be in the repository URL.
But there's no good reason to have a username at all unless users interact with each other or the web-going public, in which case the username is a public part of the URL. Services like twitter or github need @usernames. Other services should just use email addresses.
If you want your own username, don't use someone else computer. Self-host github/gitlab/gitea/whatev, and use your favorite username, without the fear of losing it.
If my username is preventing them from creating a /malware page, I'd have no problem at all with that explanation; their lack of namespacing is convenient, but can cause these problems to occur.
But why hide behind the shroud of "privacy and security" if that is the case? I'd happily relinquish (not that I have much choice in the matter) the name if it was a namespace clash.
> certain file type extensions may cause the user profile page not to load
There is no reason for this. They should always hit the same controller and be served as text/html. Why would the username ever influence this?
If that breaks an existing page then you either shouldn't have allowed the username to be created with the same name as an existing page (exactly what GitHub does) or shouldn't have created a page with the same name as a username [depending on which came first!] - or better yet, had them in a separate namespace so they cannot conflict in the first place.
The fact that usernames can break anything speaks to something profoundly wrong in general. Why should usernames be leaking into URLs instead of a surrogate key?
I mean, barring some tricks that could break layouts during rendering if people got really creative with them, why isn't any valid non-blank Unicode string a valid username?
Is it really "good practice"? It seems like cargo-cult security to me. Usernames are usually public anyway; refusing to reveal the existence of a user name as part of the login process but revealing it elsewhere in your application is pointless.
I don't think a username on someone else's service is comparable to a domain name. You buy a domain name. People go directly to your domain name. I would bet 90% or more of navigations to a github profile are linked from some other source (e.g. easy and borderline immediate to change) as opposed to typed into the url bar directly.
To be clear I think it's shitty for GH to change someone's username, especially without a lot of communication first, but I don't think it rises to the level of having any sort of damages you could try to litigate even in the worst cases.
I can't tell if you're being facetious, but a Bitcoin URI is not readable, shareable, or memorable, making it harder to use Bitcoin itself. A username, just like a URL, provides that. Not to mention, everyone can't run their own trusted server, just like most people don't run their own mail or web servers.
Even if it does, a username alone isn't a security breach. You would think they'd use ssh chroots or something, but there are no security issues with seeing a username
unique usernames are needed for nice urls like youtube.com/user/johndoe, flickr.com/photos/johndoe, etc. that's what they are for.
from the examples above, flickr username url is optional and you can stay with the ugly one, that's probably the solution you're looking for, isn't it? now you must decide which use case is easier.
I see some comments defending arbitrary "bandaid" architecture and I think that this is not defensible for something the scale of GitLab. This is basic HTTP stuff.
reply