[NEW] Delete obsolete tokens every 1 hour #7812
Conversation
|
Can you turn this into a configuration to enable it, configure the limit and cron interval? |
|
Why do we have so many resume tokens? Can we maybe address that problem instead of needing to clear out the tokens? Shouldn't the tokens expire and go away? |
|
@rodrigok , @geekgonecrazy i will check what i can do |
engelgabriel
changed the title
|
Also, does this touch the tokens generated by the rest api? As they don't expire and shouldn't until the user clicks "log out from other logged in places". Basically, if the token doesn't have an expiration date does this remove them? |
There was a problem hiding this comment.
As @geekgonecrazy mentioned, what is causing so many loginTokens that you need this? Is it because the expired ones aren't being removed? Is it because some application using the rest api isn't keeping track of the authToken and thus is logging in every single time (aka storing your username and password which is bad)?
server/startup/cron.js
Outdated
| SyncedCron.add({ | ||
| name: 'Cleanup Obsolete Tokens', | ||
| schedule(parser) { | ||
| return parser.text('every 1 hour'); |
There was a problem hiding this comment.
This isn't respecting the setting API_Obsolete_Cron.
|
|
||
| const update = { | ||
| $push: { | ||
| 'services.resume.loginTokens': { |
There was a problem hiding this comment.
I don't feel like this is a good enough query/update as it just assumes a lot of information about what is considered "obsolete". I think this could be handled a lot better
|
So far I have not found documentation on when Auth Tokens expire, I created one 2 days ago and it is still valid and works, from a security standpoint it is bad, as it opens the possibility for account breaches in case someones token/userid becomes known to a 3rd party. In my use case I am expecting thousands of users, and I wish to log them in via the iframe-authentication. The system that implements the Rocket API will be configured to hold an Admin Username and Password, so that system can create new users and request new tokens for the existing users. It would be painful to maintain a database to keep track of all the tokens, IMHO storing the userId should be enough (as that can be used to create a new token). That way I do not have to remember the users password. But that would mean that I would hit the issue of thousands of tokens to remain in the database, as they are never cleared (this PR). Especially the admin account configured that I use to create tokens (as I also do not want to remember the token of that admin account, but I do need a token, to perform the actions (aka create account/generate other user token)). So what do we need to make this PR happen? |
|
Hi, |
|
duplicated of #15102 , btw @galrotem1993 thanks for contribute ;) |
yes, why are there so many logintokens which need cleanup? and - how do you know an authtoken is expired and can be deleted? we are searching for weird intermittend automatic logout problem and came across the 50 token cron-delete job... wondering, why tokens getting created without the user doing additional logins with username/password shouldn't ONE new client create ONE new token and use that until the user logs out, especially when using the rocketchat app (as chat apps typically never logout automatically, if the user doesn't enforce it - as apps are there for people staying connected) |
|
Usually when this happens someone is using the api and using user and password frequently |
[FIX] For bug fixes
@RocketChat/core
Closes #6738
cron job for delete obsolete tokens. keeps the most new 50 tokens for every user.
the cron job runs at invoke and every 1 hour.