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
The Django SECRET_KEY is cached in the TokenBackend
The TokenBackend class sets the Django SECRET_KEY when it is initialized and then it is cached. If the first call of the APIs of the django app is from the side of any tenant, the SECRET_KEY will be cached, and the subsequent calls of the APIs, even if they are from another tenant, will use the previous SECRET_KEY and the error of invalid access token will not be given.
The text was updated successfully, but these errors were encountered:
Could you elaborate more on your use case? I struggle to understand what django.config.settings.SECRET_KEY has to do with multitenancy: SECRET_KEY is usually configured per application... It's pretty difficult for some system to have a single instance of TokenBackend and several different instances of django.conf.settings. How does your tenant logic affect SECRET_KEY setting? A short code snippet could be extremely helpful to clarify your intent.
The Django SECRET_KEY is cached in the TokenBackend
The TokenBackend class sets the Django SECRET_KEY when it is initialized and then it is cached. If the first call of the APIs of the django app is from the side of any tenant, the SECRET_KEY will be cached, and the subsequent calls of the APIs, even if they are from another tenant, will use the previous SECRET_KEY and the error of invalid access token will not be given.
The text was updated successfully, but these errors were encountered: