Session: Express Session not persisting on Safari

[jonsadka]

Hi there,

Anytime I navigate away from the page via an internal link or a refresh using Safari on a deployed environment, the session will not persist. I checked the following configurations:

Summary

✅ Chrome on localhost
✅ Safari on localhost
✅ Chrome on production using Laptop
❌ Safari on production using Laptop
❌ Safari on production using Mobile

Config

require('express-session')({
    secret: 'SuperSecretSecret',
    cookie: {maxAge: 1000 * 60 * 60 * 24 * 7 * 3},
    name: 'NormalNameThing',
    resave: true,
    saveUninitialized: true,
    store,
  })

Headers from Chrome request (on production)

{ 
  'accept-encoding': 'gzip, deflate, br',
  'accept-language': 'en-US,en;q=0.9',
  'content-length': '171',
  'content-type': 'application/json;charset=UTF-8',
  'sec-fetch-mode': 'cors',
  'sec-fetch-site': 'cross-site',
  'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko)
  'x-forwarded-for': <Redacted but same between the two>,
  'x-forwarded-proto': 'https',
  accept: 'application/json, text/plain, */*',
  cookie: 'NormalNameThing=xxxxxxxxxxxxxxxxxxxxxxxxxxxx,
  dnt: '1',
  forwarded: 'for="<Redacted but same between the two>";proto=https',
  host: '<Redacted but same between the two>',
  origin: 'https://xxxxxx.netlify.com',
  referer: 'https:/-xxxxxx.netlify.com/more-info-page/about',
}

Headers from Safari request (on production)

{ 
  'accept-encoding': 'br, gzip, deflate',
  'accept-language': 'en-us',
  'content-length': '181',
  'content-type': 'application/json;charset=utf-8',
  'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.1 Safari/605.1.15',
  'x-forwarded-for': <Redacted but same between the two>,
  'x-forwarded-proto': 'https',
  accept: 'application/json, text/plain, */*',
  credentials: 'include',
  forwarded: 'for="<Redacted but same between the two>";proto=https',
  host: '<Redacted but same between the two>',
  origin: 'https://xxxxxx.netlify.com',
  referer: 'https://xxxxxx.netlify.com/',
}

Tickets checked

I checked the following bug reports which were similar but were not the same issue

633, #638, and #610

Other notes

• Confirmed it's not a user-agent bug

[dougwilson]

Hi, I'm sorry you're having this issue. I don't have access to Safari personally, as it requires having an Apple computer. I'm not sure why it wouldn't work, but if someone can provide either a detailed break down of what makes Safari different or even a fix, I'm not sure how I can contribute in the resolution towards this.

[jonsadka]

Gotcha. Do you see anything suspicious about the headers coming from Safari versus Chrome? They do seem a bit different

[dougwilson]

The only header this module looks at is the cookie header. Of course that header is missing from Safari example so there is no way to know what session to load for that request without it.

[jonsadka]

Thank you for that, it really helpful in figuring out what was going on.

Basically, the frontend application is hosted on Netlify and the backend is hosted on Google Could. Because the communication is happening between different url's, Safari is not sharing the cookies due to Prevent cross-site tracking setting being enabled.

Will close out but if anybody has ideas on how to workaround this issue, please comment on this ticket.

Thanks!

[jonsadka]

For those curious, I was able to solve the issue by setting a CNAME record + subdomain on the backend (i.e. api.xxxxx.com) because subdomains are not considered cross-site traffic.

[Samuel-Celko]

For those curious, I was able to solve the issue by setting a CNAME record + subdomain on the backend (i.e. api.xxxxx.com) because subdomains are not considered cross-site traffic.

Hey there, I am currently experiencing the same issue - could you please elaborate on your solution as I would find it quite helpful. Thanks in advance!

[jonsadka]

For those curious, I was able to solve the issue by setting a CNAME record + subdomain on the backend (i.e. api.xxxxx.com) because subdomains are not considered cross-site traffic.

Hey there, I am currently experiencing the same issue - could you please elaborate on your solution as I would find it quite helpful. Thanks in advance!

You need to make sure your client application and backend have the same domain. So for example, if your frontend application is hosted at awesome.com, your backend needs to share that same domain. You can achieve this by using a CNAME record like <subdomain>.awesome.com

[magbicaleman]

@jonsadka

For those curious, I was able to solve the issue by setting a CNAME record + subdomain on the backend (i.e. api.xxxxx.com) because subdomains are not considered cross-site traffic.

Hey there, I am currently experiencing the same issue - could you please elaborate on your solution as I would find it quite helpful. Thanks in advance!

You need to make sure your client application and backend have the same domain. So for example, if your frontend application is hosted at awesome.com, your backend needs to share that same domain. You can achieve this by using a CNAME record like <subdomain>.awesome.com

Did you have to change anything else, curious is your sameSite set to lax? I currently have the following domain setup,
sub.domain.com, and sub.sub.domain.com, and Apple seems to be blocking still. Testing out a few different things.

[jonsadka]

@jonsadka

For those curious, I was able to solve the issue by setting a CNAME record + subdomain on the backend (i.e. api.xxxxx.com) because subdomains are not considered cross-site traffic.

Hey there, I am currently experiencing the same issue - could you please elaborate on your solution as I would find it quite helpful. Thanks in advance!

You need to make sure your client application and backend have the same domain. So for example, if your frontend application is hosted at awesome.com, your backend needs to share that same domain. You can achieve this by using a CNAME record like <subdomain>.awesome.com

Did you have to change anything else, curious is your sameSite set to lax? I currently have the following domain setup,
sub.domain.com, and sub.sub.domain.com, and Apple seems to be blocking still. Testing out a few different things.

Hmm I dont see any sameSite values being set on the cookie. Curious what the problem might be for you

[magbicaleman]

@jonsadka

For those curious, I was able to solve the issue by setting a CNAME record + subdomain on the backend (i.e. api.xxxxx.com) because subdomains are not considered cross-site traffic.

Hey there, I am currently experiencing the same issue - could you please elaborate on your solution as I would find it quite helpful. Thanks in advance!

You need to make sure your client application and backend have the same domain. So for example, if your frontend application is hosted at awesome.com, your backend needs to share that same domain. You can achieve this by using a CNAME record like <subdomain>.awesome.com

Did you have to change anything else, curious is your sameSite set to lax? I currently have the following domain setup,
sub.domain.com, and sub.sub.domain.com, and Apple seems to be blocking still. Testing out a few different things.

Hmm I dont see any sameSite values being set on the cookie. Curious what the problem might be for you

I ended up setting the "root" domain on the cookie, in my example that would be domain.com

My cookie looks like this, and works in Safari and in private browser sessions (at least Chrome, didn't test any other browser).
cookie: { maxAge: AGE, secure: true, sameSite: 'lax', httpOnly: true, domain: domain.com }

I might have been doing something wrong, but I had to open a new incognito browser session because my cookie was getting older options. Maybe some sort of response cache, or perhaps I was looking at the wrong network call in the stack.

[jonsadka]

@jonsadka

For those curious, I was able to solve the issue by setting a CNAME record + subdomain on the backend (i.e. api.xxxxx.com) because subdomains are not considered cross-site traffic.

Hey there, I am currently experiencing the same issue - could you please elaborate on your solution as I would find it quite helpful. Thanks in advance!

You need to make sure your client application and backend have the same domain. So for example, if your frontend application is hosted at awesome.com, your backend needs to share that same domain. You can achieve this by using a CNAME record like <subdomain>.awesome.com

Did you have to change anything else, curious is your sameSite set to lax? I currently have the following domain setup,
sub.domain.com, and sub.sub.domain.com, and Apple seems to be blocking still. Testing out a few different things.

Hmm I dont see any sameSite values being set on the cookie. Curious what the problem might be for you

I ended up setting the "root" domain on the cookie, in my example that would be domain.com

My cookie looks like this, and works in Safari and in private browser sessions (at least Chrome, didn't test any other browser).
cookie: { maxAge: AGE, secure: true, sameSite: 'lax', httpOnly: true, domain: domain.com }

I might have been doing something wrong, but I had to open a new incognito browser session because my cookie was getting older options. Maybe some sort of response cache, or perhaps I was looking at the wrong network call in the stack.

Interesting... I wonder what configuration option was requiring all those changes but alas, glad you were able to resolve it and glad we've been documenting all of this for others to see.