Usernames cannot be numeric

[luceos]

Currently username can be any matching regex:/^[a-z0-9_-]+$/i and the other rules (eg, min: 3). A drawback of this regex is that it allows for numeric usernames. As a consequence consider:

User

• id: 1337 username: Toby
• id: 1338 username: 1337

Hitting
/api/user/1337 returns user 1337 for any other user.

What we have to do is disallow any numeric usernames, the UserValidator has to be modified. A consideration is what to do with existing users.

[Zeokat]

In my opinion, numeric usernames are allowed on most of software and disallow them is not the way.

Maybe, when someone build an extension to integrate login with service "A" and this service allow numeric usernames, what will happen?

The problem here, is not the numeric username, is how API works.

[tobyzerner]

Open to discussing alternatives, I think the main question is what should the API call be to retrieve a single user by their username?

I guess it could be GET /users?filter[username]=Toby, although that endpoint returns a list (collection) of one users rather than a just a single resource.

[Zeokat]

Wouldn't be enough to obtain user details by its id?

[tobyzerner]

Not always. Prime example is when you browse to a user page like http://discuss.flarum.org/u/Toby - we need to look up the user by their username!

[pflstr]

Right now, we are generating duplicate content with http://discuss.flarum.org/u/Toby and http://discuss.flarum.org/u/1. Shouldn't one of them redirect to the other one or at least a canonical URL direct search engines to the version to be indexed?

[Zeokat]

Now my question changes to: Wouldn't be enough to obtain user details by its username?
(Thanks for your patience)

[tobyzerner]

Sometimes you need to look up a user by their ID too. eg. when the API returns discussions/posts, they have relationships with their authors which specify a user ID.

[clarkwinkelmann]

There could be a separate endpoint to lookup by username ? like /api/users/by-username/{value} ? There's no real need for the same endpoint to work with both IDs and usernames ?

Or tweak the existing endpoint to accept the username query with a different syntax. For example if you query /api/users/username, it acts like the GET/PUT/DELETE endpoints (or just GET) except you also have to pass a username / filter[username] GET/POST attribute to tell which username you look for. As long as it doesn't collide with the way you pass new values to PUT/DELETE it would be fine. With this solution you just have to blacklist a single token that will switch the endpoint from id-based to username-based.

It seems only profile page makes use of the endpoint with a username ?

[tobyzerner]

GET /api/users/by-username/{value} is the nicest option so far – is it compatible with the JSON-API specification? If possible we'd like to follow that as closely as possible.

[franzliedke]

Not sure if this is the right place, but I think it's the closest we have:

Ugh, I just gave this great article a good read - turns out there are some more things we need to consider in terms of username validation. And now is the best time to do so, because we can still break backwards compatibility. 😁

[cljk]

If you really think about breaking the backwards compatiblity please consider replacing the numeric IDs with something different - like UUIDs.

It´s no good idea to have a public available system and to be able to identify all users in a row by guessing IDs. Also you can guess admin-IDs (will be the first ones). like:

• https://discuss.flarum.org/u/1
• https://discuss.flarum.org/u/2
• https://discuss.flarum.org/u/3
• [...]

I could now write a script and grab all user ID´s & names. Currently this is not a huge problem - but consider flarum grows and the userpage will eventually someday show personal data like email-adress or real name or so....
That´s the reason why bigger sites switched from numeric IDs to random characters to not have their user base guessable by ID-probing.

Perhaps you could for now just disable access by ID? Because.... what is it good for?

[cljk]

Oh... and we really would later need a user-flag like login-error-count to disable after too many password tries.

I´ll lock down my installation with fail2ban and use an external auth provider... but currently there is no protection of flooding password guesses. Ok,... that is an indirect feature-request ;-)

[webagil-kevin]

+1 for disable member profile access by user ID link.

+1 for GET /api/users/by-username/{value}