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 use accounts in what is to become a multi-tenant B2B system. That is, customers are companies, each with many users. For security reasons, users are stored per company. The request headers are used to figure out which customer the user belongs to. This is used to fetch a customer specific context that is supposed to return a customer specific accounts instance, a customer specific application data instance and customer specific apollo server. AFAICT this works except for the accounts part.
In my accounts object, I had used, very naively, AccountsModule.forRoot. This led to the situation where only the last customer to be initialized would be able to authenticate users.
I have now changed the graphql modules locally to have a constructor such that I can make my own modules. What happens now seems to be that only the first customer to be initialized works instead, but now with more obscure issues.
I do something like let context = await accounts.accountsGQL.context(req);
I have issues following what happens, but it seems like I maybe am able to log on, but then, on the next request, not pick up the session such that the above call suddenly reports as unauthenticated.
So, what must I do to fully separate two (or more) accounts instances?
Edit: I am pretty sure something is going on inside the graphql-modules dependency (that is well behind the times as evidenced by the upgrade issue from 2020), but there is a lot going on there and several things appear to be able to cause the specific havoc I see. What I think goes on, assuming you have been able to create separate GraphQLModules for each of the customers (I have local changes to the graphql-api for this), is that the contextBuilding (to check if you already have an authenticated session) works fine, but then, running one of the resolvers, e.g. authenticate, it may be executed with the wrong moduleContext (injector), causing authentication to be tried against the wrong database. graphql-modules seems to go via several caches to find the context, based on the session, but it is baffling that this cache, however it works, can yield contexts from other modules as everything seems to be encapsulated.
Anyway, I gave up for now, and rewrote application to use REST for authentication.
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 use accounts in what is to become a multi-tenant B2B system. That is, customers are companies, each with many users. For security reasons, users are stored per company. The request headers are used to figure out which customer the user belongs to. This is used to fetch a customer specific context that is supposed to return a customer specific accounts instance, a customer specific application data instance and customer specific apollo server. AFAICT this works except for the accounts part.
In my accounts object, I had used, very naively, AccountsModule.forRoot. This led to the situation where only the last customer to be initialized would be able to authenticate users.
I have now changed the graphql modules locally to have a constructor such that I can make my own modules. What happens now seems to be that only the first customer to be initialized works instead, but now with more obscure issues.
I do something like
let context = await accounts.accountsGQL.context(req);
I have issues following what happens, but it seems like I maybe am able to log on, but then, on the next request, not pick up the session such that the above call suddenly reports as unauthenticated.
So, what must I do to fully separate two (or more) accounts instances?
Edit: I am pretty sure something is going on inside the graphql-modules dependency (that is well behind the times as evidenced by the upgrade issue from 2020), but there is a lot going on there and several things appear to be able to cause the specific havoc I see. What I think goes on, assuming you have been able to create separate GraphQLModules for each of the customers (I have local changes to the graphql-api for this), is that the contextBuilding (to check if you already have an authenticated session) works fine, but then, running one of the resolvers, e.g. authenticate, it may be executed with the wrong moduleContext (injector), causing authentication to be tried against the wrong database. graphql-modules seems to go via several caches to find the context, based on the session, but it is baffling that this cache, however it works, can yield contexts from other modules as everything seems to be encapsulated.
Anyway, I gave up for now, and rewrote application to use REST for authentication.
Beta Was this translation helpful? Give feedback.
All reactions