Usernames in admin URLs cause routing problems

Contribute Bug

AI-generated summary

A discussion is taking place about usernames in admin URLs causing routing problems. fefrei highlights an example where a username “list” can cause issues, as the URL admin/users/list can match the route for the list of all users. codinghorror initially suggests blocking such usernames, but sam and fefrei argue that using numeric IDs in URLs, e.g., /admin/users/1/sam, is a better solution. This approach would prevent routing issues and provide a permalink across username changes. codinghorror is hesitant due to the required engineering effort, but fantasticfears is working on relaxing username constraints in routes and applying the suggested solution to admin routes. sam confirms that a pull request has been submitted to address this issue.

1

In some places, usernames are used as part of URLs, for example in admin/users/<username>. Some usernames can therefore cause routing issues:

  1. Register a user list.
  2. Login as the administrator, go to the users list, open the details for this user.
  3. Notice that you are on admin/users/list.
  4. Reload the page. You get to the list of all users, since admin/users/list actually matches this route.

Many other URLs like users/account-created are safe, since - cannot be part of a username.

Here, this is only a small annoyance. I’m not sure whether there are more interesting cases where a similar problem can be triggered, though.

8 Curtiram
2

I will add list to the blocked usernames. Any others?

3

we really should stop with the “fancy” url thing in admin… /admin/users/1/sam … is a perfectly fine URL for an admin interface, plus knowing the user_id is actually handy sometimes when it comes to admin tasks.

9 Curtiram
4

I’m really with @sam in this case:

  • So far, the blocked usernames only contain confusing usernames (that look official or unintentional), not ones that break the system.
  • This list is admin-editable, nothing is preventing the admin from removing entries. This would have non-obvious side effects.
  • If I understand correctly, changing the default won’t affect systems which already customized the list, for example by adding an entry.
  • I have a strong feeling that there are more cases like this. I think that account-created is safe only by coincidence, not by careful consideration (“there could be a username here, so let’s add an invalid character…”).

Also, I don’t see the drawback: /admin/users/1/sam is perfectly fine for the admin’s eyes (heck, t/usernames-in-admin-urls-cause-routing-problems/31825 is fine for everyone’s eyes!), still has the slug (which is nice), and even works as a permalink across username changes!
It would also fix some issues for free: For example, after renaming a user, the back-functionality breaks, since the old URLS 404.

2 Curtiram
5

Yeah, but that takes potentially hours of engineering effort, whereas blacklisting a pointless username like “list” takes me about 30 seconds.

6

As working on the Unicode username support, the first step would be relaxing username constraints in routes. And I will also apply /admin/users/1/sam to admin routes.

3 Curtiram
7

I am pretty sure @fantasticfears submitted a PR to take care of this. My admin username path is now:

https://meta.discourse.org/admin/users/1/sam

Yes, I am #1 just like :flag_us:

7 Curtiram