4 ms·

I'm confused. What is the purpose for this? Is this for sites that have exmaple.com/username so you know ahead of time what paths you most likely want to reserv

I'm confused. What is the purpose for this? Is this for sites that have exmaple.com/username so you know ahead of time what paths you most likely want to reserve? Seems silly. You should either put users at example.com/user/{username} or you should put all non-user profiles under a reserved base like example.com/res/settings.

ljoshua 9y ago
Twitter, for example, will place the username at the first level (twitter.com/username). Most of the other interactions occur under a small group of other addresses, such as /i/ and /settings/. However, I can still see this being a helpful resource so that you don't have to think about all possibilities from the outset.
- WorldMaker 9y ago
  Some of these are also usernames that a user might use to impersonate being a part of your organization: administrator, contact_us, news, et al. That can help stop some particularly egregious social engineering attacks.
Aloha 9y ago
I guess if you have usernames in a shared namespace with system components this'd make sense - it's not something I'd consider a feature. consider: website.org/aloha website.org/contact website.org/u/aloha website.org/users/aloha users.website.org/aloha u.website.org/aloha aloha.website.org with the first two examples, yes, there is a potential for collision - so you'd want something like this. I consider the next four examples to be best - the final example I consider potentially administratively painful depending on implementation.
- 33degrees 9y ago
  Having usernames as subdomains is relatively common, and it does seem like this list has that use case in mind (see the variations on www)
- WorldMaker 9y ago
  Don't forget the ancient classic: website.org/~aloha Mastodon's interesting approach: website.org/@aloha
  - Aloha 9y ago
    yeah, I neglected those. I still use ~ on a couple web servers I administer, easy way for me to give people a sandbox attached to their user.
adambrenecki 9y ago
I agree. Even if you think /user/ or /res/ is too long or unsightly, you could have shorter prefixes like (in an example.com/username system) example.com/.settings or example.com/_settings, or (in an example.com/settings system) example.com/@username or example.com/~username. That said, it might still be a good idea to blacklist these anyway, as you might end up with someone registering the username 'reset-password' (which isn't on this list yet) trying to phish your users, or 'support' trying to masquerade as your support, depending on what your app does.
twhb 9y ago
Certainly doing this is introducing technical challenges easily avoided. But it’s also a win for reading, typing, and remembering URLs. Don’t confuse back-end elegance with elegance in communication with humans.

ljoshua 9y ago

Twitter, for example, will place the username at the first level (twitter.com/username). Most of the other interactions occur under a small group of other addresses, such as /i/ and /settings/. However, I can still see this being a helpful resource so that you don't have to think about all possibilities from the outset.

WorldMaker 9y ago
Some of these are also usernames that a user might use to impersonate being a part of your organization: administrator, contact_us, news, et al. That can help stop some particularly egregious social engineering attacks.

Aloha 9y ago

I guess if you have usernames in a shared namespace with system components this'd make sense - it's not something I'd consider a feature. consider: website.org/aloha website.org/contact website.org/u/aloha website.org/users/aloha users.website.org/aloha u.website.org/aloha aloha.website.org with the first two examples, yes, there is a potential for collision - so you'd want something like this. I consider the next four examples to be best - the final example I consider potentially administratively painful depending on implementation.

33degrees 9y ago
Having usernames as subdomains is relatively common, and it does seem like this list has that use case in mind (see the variations on www)
WorldMaker 9y ago
Don't forget the ancient classic: website.org/~aloha Mastodon's interesting approach: website.org/@aloha
- Aloha 9y ago
  yeah, I neglected those. I still use ~ on a couple web servers I administer, easy way for me to give people a sandbox attached to their user.

adambrenecki 9y ago

I agree. Even if you think /user/ or /res/ is too long or unsightly, you could have shorter prefixes like (in an example.com/username system) example.com/.settings or example.com/_settings, or (in an example.com/settings system) example.com/@username or example.com/~username. That said, it might still be a good idea to blacklist these anyway, as you might end up with someone registering the username 'reset-password' (which isn't on this list yet) trying to phish your users, or 'support' trying to masquerade as your support, depending on what your app does.

twhb 9y ago

Certainly doing this is introducing technical challenges easily avoided. But it’s also a win for reading, typing, and remembering URLs. Don’t confuse back-end elegance with elegance in communication with humans.