Need help on API registration. Security concerns
-
@julian , Where exactly we can make changes if we wanted to? I think it should be relatively easy to put a limit.
-
@hellowmellow For now, the easiest way would be to do it in nginx via
limit_req_zone
. You can configure the directive so that it only affects the/api/v3
path.I'm looking at adding it to core now.
-
@julian said in Need help on API registration. Security concerns:
configure the config
I think I know what you wanted to tell us, but the choice of words is quite funny here
-
@julian cool. Also, a quick question. Is there a way to add for the api to check if the user already exists and then prevent registration instead of appending digits and letters to the newer ones? Maybe something like this:
// Check existing const existingUser = await user.getUidByUsername(username); if (existingUser) { return helpers.formatResponse(400, res, { message: 'Username not available' }); }
-
@hellowmellow You can use the
HEAD /api/v3/users/{uid}
call to check before making the registration call.https://docs.nodebb.org/api/write/#tag/users/paths/~1users~1{uid}/head
-
but that's uid, not username ... Am I thinking different?
I guess I am confused on how uid can check if the username already exists. We wouldn't know the uid of the username guest is trying to register for.
-
@hellowmellow No, I was mistaken. Call
HEAD /api/v3/users/bySlug/{slug}
instead. It's the same route, but thebySlug
part allows you to pass in a user slug instead of a uid. -
oh ok. Let me try that. I will wait on if you figure something about rate limit in the core. I will share what I find as well. Cheers!
-
@julian , hey man another quick question I totally forgot to ask. Is there a way to not allow registration if the email is already used via this register api?
Thanks. -
@hellowmellow no, because email is not a part of registration. It is only added to the account once confirmed .
For more info see: https://community.nodebb.org/post/91260
-
Thanks @julian .
If anyone comes to this thread in future. I solved this issue by using a rate limiter in the backed server. For now, it suffice the concerns I had.
But being able to access the rate/ip limit via the api itself would always be preferable. Cheers!
-
-