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
I am writing a multi-tenant application which uses email as the username and I'm using this library to associate various bits of data (including users) with tenants.
When it comes to user authentication, there is a chance that the same email address will be used for multiple users - but on different tenants.
If I supply the tenant's API key with the request, everything works fine - my custom authentication backend plucks out the API key, finds the tenant and looks up the user from the combination of email and tenant.
But if I don't provide the API key in the request, then the lookup for the key goes wrong. I was hoping that I could use HasAPIKey in my DRF default permissions and that that would cause a 403 error (or maybe a 401) but I think it hits the authentication part first and so this setting is never used.
Does that make sense? And if so, is there any way around this, do you know?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I am writing a multi-tenant application which uses email as the username and I'm using this library to associate various bits of data (including users) with tenants.
When it comes to user authentication, there is a chance that the same email address will be used for multiple users - but on different tenants.
If I supply the tenant's API key with the request, everything works fine - my custom authentication backend plucks out the API key, finds the tenant and looks up the user from the combination of email and tenant.
But if I don't provide the API key in the request, then the lookup for the key goes wrong. I was hoping that I could use HasAPIKey in my DRF default permissions and that that would cause a 403 error (or maybe a 401) but I think it hits the authentication part first and so this setting is never used.
Does that make sense? And if so, is there any way around this, do you know?
Beta Was this translation helpful? Give feedback.
All reactions