Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: for controllers/services that don't need tenant. How to bypass the tenant validation #27

Open
raphaelarias opened this issue Jun 16, 2022 · 6 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@raphaelarias
Copy link

For some controllers, (e.g. /v1/tenants/create) we don't have the tenant id yet, because in this case, for example, they are actually creating a new tenant.

We were trying not to set the X-TENANT-ID as null or something just for the sake of it. Is there a way to for certain controllers to bypass the validator? We studied rolling out our own validation, but if/before we do that, I thought it would be better to ask. :)

@sandeepsuvit
Copy link
Contributor

@raphaelarias interesting question. In the current implementation the tenant context is resolved from the request scope. So this means all requests to the controllers under tenant module implementation should comply to pass this information for this to work. According to your requirement how would you want to get this working? Any suggestions?

@raphaelarias
Copy link
Author

That's an interesting question, for which I don't have the answer yet. Maybe a decorator for specific controllers?

@sandeepsuvit
Copy link
Contributor

@raphaelarias would you like to give it a try via a PR.

@sandeepsuvit sandeepsuvit added enhancement New feature or request help wanted Extra attention is needed labels Jun 23, 2022
@AdamJessop
Copy link

I have just been looking at this, and would need substantial refactoring, the problem is that all of the checks for the tenant key is done in the module instantiation, which is executed before any of the guards.

One solution would be to have a tenancy middleware which could get applied to routes at an inheriting module level, but even that feels clunky when working with Nest and how nice using decorators are.

The best way forward would be to set the tenantId the request, and if the tenantId isn't set it should skip the validator and degrade gracefully. Then an AuthGuard could be written at a controller level to check for the presence of tenantId and if needed, throw an error.

@AdamJessop
Copy link

That PR above will get the ball rolling I guess.

@samuelpares
Copy link

samuelpares commented Aug 3, 2022

Perhaps in this case, the module associated with your route /v1/tenants/create should not import TenancyModule or any other module that imports it. Then you can just create a new mongoose connection, do stuffs you need and close it, or even use the default MongooseModule to connect to a predefined database and inject models in your services. I speak from experience, since I'm doing the same thing you are trying to.
With this PR, what would happen with a skipped route that has some service that injects a model using InjectTenancyModel?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants