Namespace issue with the '/u/' static routes

Most static routes in the /u/ (/users or /user) path haven’t been fully protected against interference with the /u/:username path structure.

account-created (i.e. /u/account-created) has been protected. It has a

  • url re-write exception (i.e. to prevent /u/account-created being rewritten to /u/account-created/summary; and
  • appears by default in the reserved-usernames site setting.

However the rest of the static routes in the /u/ path have not. For example, you can register password-reset as a username, but when you try to go to your profile you see:

The same applies for all the server routes in the /u/ path apart from account-created, i.e.

  • admin-login
  • email-login

For most of these you get a 404 error if you use it as a username and then try to go to your profile.

This is a relatively minor issue as it is highly unlikely these static path names will be used as usernames, but it is still technically a ‘bug’.

In addition to protecting these other static routes, you may want to consider whether it makes sense to use a site setting to prevent people using static /u/ routes as a username.

There are no circumstances in which you can change this setting and not create the issues mentioned above, unless you also change the static routes themselves. The static routes are hardcoded, so the username exceptions should probably also be hardcoded.


Agreed, can we add these to the disallowed usernames out of the box @techapj? We already have several disallowed usernames in the codebase as defaults, should be fine to add more.


Fixed via:

Thanks for reporting this issue @angus. :+1:


I think the proper solution here is not to add those routes as reserved usernames but instead have those controller actions be served via a different route like “/account/admin-login”. Otherwise, we are bound to repeat this mistake when someone adds another route under the scope of /u. Another alternative is to wait for us to deprecated /users in favor of /u and have those actions be served under /users.


Right, but until that work is scheduled and completed, this is a “good enough for now” fix. We already have a number of disallowed usernames out of the box, adding a few more is no big deal.