How to share cookies between Medusa and the store front in production (DigitalOcean)?

[goodpixels]

I'm building a storefront with Nuxt.js and I am having issue maintaining user sessions when I deploy my app to Digital Ocean, but everything works fine locally. I suspect it's due to the fact that on localhost both the Medusa backend as well as the Nuxt front-end share the same domain, thus they can read each other's cookies, whereas once deployed to Digital Ocean, they live on different domains.

Storefront is deployed to http://my-super-store.com (a made up domain name of course) and Medusa is deployed onto a subdomain: http://api.my-super-store.com.

I tried specifying the domain name for the cookie within my front-end code, according to Nuxt's documentation: https://nuxt.com/docs/api/composables/use-cookie#domain, but it does not seem to work.

I tried the following:

const cookie = useCookie("connect.sid", {
  domain: "http://my-super-store.com"
})

const cookie = useCookie("connect.sid", {
  domain: "http://api.my-super-store.com"
})

const cookie = useCookie("connect.sid", {
  domain: "http://my-super-store.com:3000"
})

const cookie = useCookie("connect.sid", {
  domain: "http://api.my-super-store.com:9000"
})

None of these seemed to have fixed the problem - as soon as the user logs in from the storefront and refreshes the page, the session is lost, because no cookie is set.

Can anyone help me resolve this? This is a major problem for going live.

Many thanks,
John

[pevey]

The browser will not let you specify a domain name that does not match what the browser is actually accessing. That setting will not let you set a cookie that doesn't match the origin the browser has requested. The browser will just reject it. If you think about it, this makes sense. If browsers allowed this, it would be a massive security issue, and chaos would ensue. The setting exists because the app might not know the domain. It is probably running on localhost and being proxied, all handled by DO.

The same domain issue has to do with restrictions in Safari on third-party cookies, which or often used for tracking. If the cookies is coming from a different root domain, Apple assumes it is sketchy. So you want to have the same root domain, which it seems you already do. So the domain name is likely not your issue.

Check the browser console Application tab under cookies to see if the cookie is being set. If it is there, then the browser is accepting it.

[goodpixels]

Thanks for a reply, I'm not quite sure if I understood everything, but let me play that back to you: because the cookie is set by Medusa on subdomain (api.my-super-store.com) that means that the front-end will never be able to read it, because it cannot access a different origin, HOWEVER, it should be possible the other way around - that is if it was the front-end setting the cookie on the root domain (my-super-store.com) then the cookie could be read from the subdomain (api.my-super-store.com) because they share the same domain?

[pevey]

The storefront app client runs in the browser, and that part of the app can read the cookie and send it direct your browser to send the cookie to your medusa backend. (edited to avoid confusion- the app can't access the value) The storefront app is a puppeteer directing the browser in how to make requests to your medusa backend. The requests are not routed through the storefront app. The browser and the backend talk to each other directly. This is the way the medusa js and medusa-react clients are designed. As a side note, the SvelteKit client is designed differently. It runs on the server. You can do that as well. You don't have to use a client. You can make calls directly to your medusa backend from your storefront app. But if you want your storefront app server to have access to the session cookie, you have to manage the login flow in your app, grab the session cookie header from a successful login response, and set that cookie yourself from your storefront app. Then, make requests to the backend by passing along that cookie. This how the SvelteKit client works.

[pevey]

Another side note as to the why of it: Medusa's popularity grew around the same time that "JAMstack" frameworks were becoming very popular. The design of the react-client allowed all javascript code to be browser-side. The storefront server could serve completely static code that ran in the browser and talked to the medusa backend. That was de rigueur at the time. Tastes have shifted somewhat since then (favorably, in my opinion) back toward full-stack storefront apps.

[goodpixels]

Thanks, I will try to figure it out and will post back once it's resolved, or will come back with more questions. Thank you!

[goodpixels]

Okay, so I guess what I need to is login the user via the front-end, and save connect.sid as a cookie also from the front-end, then in subsequent requests check if the cookie has been set or not. The question is though, how can I obtain connect.sid value via the Medusa JS client or via the Store API?

[pevey]

Yes, exactly. You can send the request to ://backend/store/auth from your storefront app and intercept the headers from the response. You can’t do this using the official medusa clients, but you can still do it. I’m on mobile so it’s difficult to link now, but take a look at the sveltekit-medusa-client library. It’s short, one file. It talks directly to the medusa backend. Everything in medusa is exposed via api routes. You can follow a similar approach with NUXT.

[adamcanray]

@goodpixels are you be able to get the connect.sid?

also, @pevey how to intercept the headers from the response?i've try this:

....
  const response = await fetch(env.NEXT_PUBLIC_BACKEND_URL + "/store/auth", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ email, password }),
    })

    console.log("response", response)

    const headers = response.headers
    headers.forEach((value, name) => console.log(name, value))
....

it only returns:

cache-control private
content-type application/json; charset=utf-8