search

RocketChat / Rocket.Chat

The communications platform that puts data protection first.
https://rocket.chat/
Other
40.38k stars 10.5k forks source link

[BUG] users.update REST API endpoint is inconsistent on user deactivate and depends on user's chats ownership #19307

Open ankar84 opened 4 years ago

ankar84 commented 4 years ago

Description:

I'm using REST API scripts to get userId and deactivate user in a moment when that user is disabled in Active Directory I see that result of scripts using REST API is inconsistent - some users get deactivated without any issues, but sometimes script finishes with 400 error:

[2020.08.31 05:38:36][Error] Error: The remote server returned an error: (400) Bad Request.
[2020.08.31 05:38:36][Info] RC_UserID : System.Net.WebException: The remote server returned an error: (400) Bad Request.
at Microsoft.PowerShell.Commands.WebRequestPSCmdlet.GetResponse(WebRequest request)
at Microsoft.PowerShell.Commands.WebRequestPSCmdlet.ProcessRecord()

I try to deactivate user, that get error in script - and I successfully deactivated him in Admin UI

Steps to reproduce:

  1. Try to deactivate user via REST API
  2. Get 400 error sometimes

Expected behavior:

Consistent working of deactivate script

Actual behavior:

Some REST API deactivations stops with 400 error

Server Setup Information:

Client Setup Information

Additional context

I see this now on 3.6.3 server version, but we checked logs, and see that it was on 3.1.1 before upgrade Account which token used in scripts has Admin role in Rocket Chat

Relevant logs:

[2020.08.31 05:38:36][Error] Error: The remote server returned an error: (400) Bad Request.
[2020.08.31 05:38:36][Info] RC_UserID : System.Net.WebException: The remote server returned an error: (400) Bad Request.
at Microsoft.PowerShell.Commands.WebRequestPSCmdlet.GetResponse(WebRequest request)
at Microsoft.PowerShell.Commands.WebRequestPSCmdlet.ProcessRecord()
pierre-lehnen-rc commented 4 years ago

Do you have any logs from the Rocket.Chat side?

ankar84 commented 4 years ago

Do you have any logs from the Rocket.Chat side?

I did this -In Kibana from HAProxy logs get 400 response current time, and then checked RC logs in that time - nothing. What can I do to debug that issue?

ankar84 commented 4 years ago

@pierre-lehnen-rc that issue is still reproducible on users who gets error on script deactivate. Now I try to deactivate that users via powershell scripts by manually launching them with my personal admin token - and still 400 error. First I thought maybe data for that accounts is too large for some reverse proxies on network path and cleared couple of large attributes like keycloak and ldap - no luck Now I think, that problem could be in rooms. Here is en example of rooms of one users with problem

"__rooms" : [
                "3fnXHdmiFEariP23N",
                "aWhYSTcZooypbEbkJ",
                "Ht6qviY3AxvefrCNX",
                "ZmZmv9Z3XqoyMTYuZ",
                "FmooDnEQCCHBsdueZ",
                "HWxiaiiLud7bTCcCr",
                "zPtcTpJzrCJAgk5ZX",
                "4BnZDoWdPbuyGCcdA",
                "kej9Mn8rYH74mpcD7",
                "uPa9ETP7cwDGAJLdY",
                "f8ZJzpaB3GgdPRzwG",
                "DbG47BmXyckqgx8Lt",
                "J5myvqRNWiuE3mCMc",
                "wpygefTzbYnR53dnA",
                "LPNqxFX4KpaWYLJr7",
                "yHFDALEiczRc6JNAn",
                "NZ9zcFxjdoYYwPeY6",
                "Zpmc3qxCu7PDqH55j",
                "xgcY8vCAPZgDAGJFo",
                "6mkv7tvrJAmi4AJrR",
                "BqucKbbuTtLwDSqPy",
                "mxdGcssusr7Q5nsny",
                "PEwZDykzPh7ePDGYD",
                "CGf9hdPvw885vy8hs",
                "hXgb2F54JGHc84GxL",
                "7hQg6ew7yNKA4ShkF",
                "5W2uXEkb5njBwPLfN",
                "erMPed4QPB5nGXuea",
                "fh5CgKwes9REFwuo5",
                "dGRZ3fbwbH8gBPmnq",
                "84KNdmuqEYis26JTJ",
                "5uDcmxyKskENnBkGF",
                "X6tQLCskzujsmmpdc",
                "MwaauHFGTTRihasFM",
                "krMyqYPX6ox5fpi4d",
                "ruZxCk5pQRj4c7Dnn",
                "bhDwpeLq7fd5yNcor",
                "eDfXqZRceqzh6AbcN"
        ],

Maybe that array to large for REST API?

ankar84 commented 4 years ago

Maybe that array to large for REST API?

No. Just deleted that "__rooms" object and try to deactivate user again - no luck (400 response code)

ankar84 commented 4 years ago

And here is a deactivate attempt in Admin UI image

And yes, after that on mongo I see "active" : false, for that user And deactivate script now returns true

ankar84 commented 4 years ago

I activate that user again in Admin UI and try to deactivate via REST API by powershell script again. And now all fine! I get true, and not 400 Bad Request. I don't know how to fix that. Maybe @sampaiodiego can clarify that? Now I have about 100 problematic users like that, so I can try to fix in a various ways ;)

ankar84 commented 4 years ago

Confirmed that if I deactivate user in Admin UI then deactivate script via REST API start to work normally on another user. How do Admin UI deactivate user? Not via REST API in fact?

ankar84 commented 4 years ago

Just deactivated in Admin UI another user and according mongodb document for that user changed only 2 fields: "active" and "_updatedAt" which is really logical. So, I'm almost 100% sure, that ussie itself not in user with it's attributes, but in all room, that user created and where he is only one owner. In Admin UI I see this: image And I believe that is a root cause for that error - REST API could not reassign new owner for deactivated user rooms so it return 400 error. Admin UI can do that easily. @pierre-lehnen-rc what do you think?

pierre-lehnen-rc commented 4 years ago

If that was the cause you should get a 'user-last-owner' error, but I'll try to replicate the situation here.

ankar84 commented 4 years ago

If that was the cause you should get a 'user-last-owner' error, but I'll try to replicate the situation here.

Yes, please test it, it's really easy to replicate. For now it is a bit security issue for us, because we deactivate users in RC in moment of disable user in LDAP (when user resigns the Company). User should lost access to Rocket Chat in that moment.

ankar84 commented 4 years ago

Just tested that bug in a pure docker image of version 3.7.1 in test environment image Удаленный сервер возвратил ошибку: (400) Недопустимый запрос.

ankar84 commented 4 years ago

I think issue could be here in these two lines https://github.com/RocketChat/Rocket.Chat/blob/287d1dcb376a4613c9c2d6f5b9c22f3699891d2e/app/api/server/v1/users.js#L471-L472

And here is how it's done in Admin UI https://github.com/RocketChat/Rocket.Chat/blob/1e7b31d199b32c2afbf9ea098b4bbe54d05e534e/client/admin/users/UserInfoActions.js#L126-L145 I will try https://docs.rocket.chat/api/rest-api/methods/users/setactivestatus endpoint instead of users.update

Yeap - that endpoint work like a charm! image

ankar84 commented 4 years ago

Full solution for me https://forums.rocket.chat/t/ldap-auth-disabled-ad-users/1715/14 But I think, that if users.update have ability to deactivate user it should be fixed. Or it should be 2 separate functions (endpoints) - so, deactivate function must be removed from users.update in that case.