You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the only way to prune the database of old tokens in the blacklist app is to run a manage.py command. It's simple if you have a cron job or celery to run Django's call_command.
However, if you take into consideration most users will be following a practice of
obtaining both tokens
refreshing the access token
refresh token eventually expires, the frontend is told that it has expired, and, if user credentials are saved, repeat from step 1.
During step 3, if the refresh token is valid / is just simply expired, then we can send a delete op to the db to prune it. This doesn't resolve the problem of the frontend itself deleting its tokens saved on its keychains/cookies or clients who delete the app and thus a refresh token is never sent. Ofc, the workaround is to always prune on every new expiration (don't think it'd be a good idea for the obtain view). Thoughts?
The text was updated successfully, but these errors were encountered:
Currently, the only way to prune the database of old tokens in the blacklist app is to run a manage.py command. It's simple if you have a cron job or celery to run Django's
call_command
.However, if you take into consideration most users will be following a practice of
During step 3, if the refresh token is valid / is just simply expired, then we can send a delete op to the db to prune it. This doesn't resolve the problem of the frontend itself deleting its tokens saved on its keychains/cookies or clients who delete the app and thus a refresh token is never sent. Ofc, the workaround is to always prune on every new expiration (don't think it'd be a good idea for the obtain view). Thoughts?
The text was updated successfully, but these errors were encountered: