Client SDK "signIn" doesn't refresh tenant cookie

[mdconn]

This is a DX question/discussion about the Client SDK. Let's say we build our own SignInForm, and we use the signIn function from @niledatabase/react.

We end up with something like this:

const response = await signIn('credentials', { email, password, });

What I have noticed, testing with different users and tenants, is that the nile.tenant-id cookie is stale and not refreshed after a signIn. Thus I end up seeing data from the previous tenant, unless I do a manual page refresh, in which case the cookie gets properly refreshed. This has caused me quite a bit of running around trying to figure out the best way to automatically refresh the tenant cookie after a signIn.

I ended up having to build a custom route handler, and needing to redirect to that in order to Get the user's default tenant Id and set it to the cookie. Not super clean or ideal. Maybe I'm completely missing something, but I'm positive that this signIn method isn't adequately refreshing tenant-id cookie, and it requires some brute force:

const response = await signIn('credentials', {
      email,
      password,
      callbackUrl: '/auth/post-login', // Get user's default tenant Id from nile.users, set tenant-id cookie, redirect somewhere...
});

Can we do something with signIn to make the cookie refresh more completely, so that tenant-id isn't stale, or perhaps I'm totally missing the easy way to do this with the signIn method?

[jrea]

The core of this problem lies in the fact that a user can be belong to many tenants. The basic question is if the user is part of 2 tenants, which one is the correct tenant id? There would been to be something done in order to determine correctness.

On the one hand, you could sign in and we look at the existing tenantId. It's there, the user is part of it, great, we can continue (this is the default behavior).

User is part of 2 tenants, but their tenantId is pointed at their first tenant. This isn't necessarily wrong, since we only know the "active" tenant is the one in the cookie / set in the sdk. If a user creates a 2nd tenant, does that mean it is the active tenant? The SDK does not have an opinion on that.

What should be happening:

If a user is part of 1 tenant, the tenantId should automatically be set in the cookie, which is then synced via @niledatabase/nextjs. If the user is part of 2 tenants, it will use whatever is in the cookie (will be stale of a newer tenant2 is created, it's not automatically set on tenant creation . This requires some opinion on the "correct" tenant, which the SDK does not handle. It only handles the binary case where we know it's correct).

This should not persist across signIn for users. In a quick look of the code, it looks like we are only checking for the existence of the cookie, nothing more (should match user + tenant). I will revisit it to ensure the above expected behavior is happening. niledatabase/nile-auth#123

[mdconn]

yeah I understand the multiple tenants question. Perhaps first tenant in the list could be the default that is set in cookie/context for a fresh signIn, but yeah I think the bigger issue pertains to what you noticed:

In a quick look of the code, it looks like we are only checking for the existence of the cookie, nothing more (should match user + tenant).

So from my testing, I was using some test accounts, each user belonging to only 1 single tenant. What I noticed, when signing out and back in, is that the old and stale tenant-id, from a tenant that the current user doesn't belong to at all, is what persisted in the cookie, and needed to be forcibly changed with my auth/post-login solution.

I think the ideal scenario is that when a user signs in, the SDK ensures that the first tenant-id from their list gets set to the cookie, ensuring that no stale/erroneous tenant-id exists there, and then you allow user to switch tenant using your existing components/SDK methods.

[jrea]

Yup, what you're seeing correlates to what I saw in the code.

the SDK ensures that the first tenant-id from their list gets set to the cookie, ensuring that no stale/erroneous tenant-id exists there

You've convinced me. I'll let you know when this is fixed (shouldn't require any SDK changes, famous last words)

[jrea]

Sorry this took so long, I found a bug related to this that was a bit gnarly to fix, but all of this should be better in 5.1.x, but even without the upgrade, the API should be more aggressive at dealing with tenant ids.