[Workaround] Help - dbAuth session cookie collision in CHROME

Get Help and Help Others
1

NOTE: this only happens when I try to use CHROME to access both sites

I’ve been using dbAuth and I’m finding that the session cookie collides somehow

I have two RW apps with separate deployments pointing at the same Supabase.io database

These two apps are deployed under the same domain, i.e. abc.pdq.com & xyz.pdq.com

Even tho’ the apps are sharing the same Database, each app uses a different auth table

I can’t login two both these apps at the same time WITH CHROME – somehow the first applications cookie (with domain abc.pdq.com) collides with the second applications cookie (for xyz.pdq.com)

If I login to abc.pdq.com using the first app – then my session cookie for the second app is then invalidated and I have to re-login on the second app – which invalidates the cookie on the first app (etc., etc.)

Does anyone know what CHROME’s problem is?

Each session cookie specifies the full [host].[domain].[tld]

2

Just to clarify you are logged in as the same user account on two different browser sessions.

But when the second user logins in or whatnot then the first user’s cookie is invalidated?

That may be expected but would have to check with @rob.

3

NOTE: further, more careful testing [with Coffee™] reveals that this problem only rears it’s head when I’m in Dev working on localhost

WORKAROUND: when in Dev use two browsers

In any case:

One login is with email+password and the 2nd login is with phone+SMS-Code

Tho’ I’m sharing the same Supabase database these are two otherwise separate Netlify apps

Also, this problem only shows up in Chrome – so I’m declaring this a Chrome thing

And closing out this post

As always, thanks @dthyresson

  • Redwood Rules !
    authModelAccessor: 'validatePhone',

    // A map of what dbAuth calls a field to what your database calls it.
    // `id` is whatever column you use to uniquely identify a user (probably
    // something like `id` or `userId` or even `email`)
    authFields: {
      id: 'id',
      salt: 'salt',
      username: 'phone',
      hashedPassword: 'hashedPassword',
      resetToken: 'resetToken',
      resetTokenExpiresAt: 'resetTokenExpiresAt',
    },

and

    authModelAccessor: 'user',

    // A map of what dbAuth calls a field to what your database calls it.
    // `id` is whatever column you use to uniquely identify a user (probably
    // something like `id` or `userId` or even `email`)
    authFields: {
      id: 'id',
      username: 'email',
      hashedPassword: 'hashedPassword',
      salt: 'salt',
      resetToken: 'resetToken',
      resetTokenExpiresAt: 'resetTokenExpiresAt',
    },
1 Like
4

Yeah in dev since the host is always just localhost the cookies will override each other since they have the same name session.

One way around this would be to use an incognito window for one domain and a regular window for the other. Then you could be logged in to both without overwriting each other’s cookies.

I suppose we could let you customize the name of the cookie if you wanted, so that you could give each app a unique name and their cookies wouldn’t collide…hmmm…

5

Oddly I do not have the same problem in FF or Safari – so I could also: just not put both in chrome – I’ve been running one or the other in a different browser

cheers!

1 Like