Rocket.chat: API save/update user RateLimiter when logged in as Admin

[AlecTroemel]

Rocket.Chat version: 0.47

Currently, If you hit the user.create or user.update routes while logged into the api as admin, you are still limited to the RateLimit of functions

• setUsername here https://github.com/RocketChat/Rocket.Chat/blob/develop/packages/rocketchat-lib/server/functions/setUsername.coffee#L65
• setEmail here https://github.com/RocketChat/Rocket.Chat/blob/develop/packages/rocketchat-lib/server/functions/setEmail.js

I believe this is because in the RateLimit function https://github.com/RocketChat/Rocket.Chat/blob/develop/packages/rocketchat-lib/server/functions/setEmail.js, userId is the id of the user who's email/username you are updating, not the userId of the user making the call (this.userId() or Meteor.userId()).

If the user has the permission edit-other-user-info, they can only edit their own username without any limitations (or those users who also have the permission edit-other-user-info). This seems to be different then the intended purpose of the line

return not userId or not RocketChat.authz.hasPermission(userId, 'edit-other-user-info')

which to me means admins (or those with that permission) should be able to update those values without the rate limit.

At the very least a rate limit of 1 minute between updating an user's email from the API while logged in as the admin seems rough to me.

Thoughts?

[graywolf336]

@sampaiodiego Thoughts/comments on the above?

[sampaiodiego]

the comment on that doesn't reflect the behavior anymore. but I agree it should behave.

it's a bug I introduced on the last changes.

[kginstructor]

This is still an issue in 0.50.1. I forked to go in and see if I could save you some time and fix it, and it looks like, code-wise, it's fixed on the develop branch; although I wasn't able to test yet. What is the status of this at the moment?

[hexus]

This is still a problem for me. Our RocketChat integration at Claromentis needs to be able to update many users in quick succession if their details have changed.

Can this limit be made configurable, or be removed when authenticated with an admin account?

[Galatoni]

I've started running into this issue when attempting to mass change users information via the users.X endpoint. This only seems to be a fairly recent thing though.
This is really causing us a lot of problems now and I can't see an easy way of lifting the rate limit for admin users.

[winterstefan]

I can confirm this issue, too.

it's a bug I introduced on the last changes.

@sampaiodiego May I ask whether there's a plan on fixing this? Or do you have tip on how to bypass this issue?

Since we have a custom chat implementation by using REST & Realtime API, we currently try to sync user data (e.g. username) from our primary data source to Rocket.Chat.

As for the initial sync command, we ran into the mentioned rate limit. Although we might be able bypass it for the initial sync, the problem will occur in production as soon as x users update their profile simultaneously.

---

Detail information

Here are some information about my setup/test. If you want, I surely can give further information or add another, up-to-date, bug report.

I can confirm having trouble with updating user data for regular users from an admin account (via API).

My setup for testing:
Calling Realtime API users.update to send 100 consecutive calls with a random username

Test case | Result | Details
------------ | ------------ | ------------
Use API as admin, update a regular user | ❌ | error-too-many-requests after about 20 (?) requests
Use API as admin, update a regular user, give regular users the permission edit-other-user-info | ✅ | Successfully sent all 100 requests
Use API as admin, give the regular user the admin role, update this user | ✅ | Successfully sent all 100 requests

So yeah, I got it working. But none of both succeeded test cases are an option for a production setup.

Seems like the rate limiter (at least for users.update - may affect others) does evaluate the userId of the wrong user.
Any ideas?

---

And just for my information

I tried tracking down the issue to find the actual rate limit specification.

• packages/rocketchat-api/server/v1/users.js contains the users.update endpoint -> saveUser is called
• packages/rocketchat-lib/server/functions/saveUser.js -> setUsername (and others) is called
• packages/rocketchat-lib/server/functions/setUsername.js -> contains a rate limit of 1 per minute

In my tests, it looked like more than 1 req/min was handled correctly before running into the rate limit. Did I catch the wrong kind of rate limit specification?