Replies: 3 comments 1 reply
-
Forgot to mention that the middleware is applied only if the request is stateful:
for the token based authentication, we can add an ability to the generated token to scope it to a tenant. |
Beta Was this translation helpful? Give feedback.
-
Hey @niktsanov, thanks, I'm glad you like it. If you're using the session override, and the login routes are within a tenanted route group, which uses the subdomain identity resolver, the cookie created by the backend should automatically be scoped to the subdomain. So if you changed the subdomain in the URL, it wouldn't send the cookie. |
Beta Was this translation helpful? Give feedback.
-
@niktsanov Though I suspect I may be misunderstanding the issue you're facing. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hey @ollieread, great package, I really appreciate the simplicity of it!
I'm playing around with it for an existing production application where we want to implement a shared database, shared schema multi-tenancy.
We are authenticating an SPA, so we are using the session-based Sanctum authentication (not token based). Every tenant has a subdomain and we want the session to be scoped to that subdomain, so we have the following configuration:
That said, since we are not scoping Redis per tenant (shared store for all sessions), someone could technically hijack a session from a tenant1.thankbox.test (change the domain) to tenant2.thankbox.test and be authenticated there.
We've resorted to creating a middleware
EnsureValidTenantSession
(inspired from spatie's multitenancy package) for dealing with this:I'm wondering if you have any plans on supporting scenarios like this in the package or is it out of the scope? Maybe you have plans for other way of handling this?
Beta Was this translation helpful? Give feedback.
All reactions