Gotrue-js doesn't set a cookie

hi,

I’m playing around with gotrue-js and now I want to keep my users logged in. Also after refreshing the browser

I have this redirect urls

[[redirects]]
  from = "/privat/*"
  to = "/privat/:splat"
  force = true  # ensure that we always redirect
  status = 200  # do not update the url
  conditions = {Role = ["guest", "admin"]}

[[redirects]]
  from = "/privat/*"
  to = "/login"
  force = true
  status = 302  # update url

and now I wanted to set a cookie, that it can be used for authentication for the redirect rules above

const auth = new GoTrue({
  APIUrl: 'https://appname.netlify.app/.netlify/identity',
  setCookie: true,
  audience: ''
})

but the cookie is never set, what I’m doing wrong?

I also added the remember flag at the login

this.$auth.login(this.credentials.user, this.credentials.password, true)

but this only creates a localstore entry “goetrue.user: {…}”

any ideas?

gregor

There are 2 ways to go about this:

  1. Check in the response headers, if the set cookie headers exists. If it does, chances are the cookies are being blocked on the browser-level. If not, there’s something even weird happening.

  2. Don’t use GoTrue JS. You can directly use Axios, or Fetch to do the same thing. For example, a login attempt would look like:

axios: Axios.create({
  baseURL: 'https://site.netlify.app/.netlify/identity',
  headers: {
    'x-use-cookie': 1
  },
  method: 'post'
}),
login() {
  this.axios({
    data: `grant_type=password&password=${encodeURIComponent(this.password)}&username=${encodeURIComponent(this.email)}`,
    url: '/token'
  }).then(({data}) => {
    this.save(data).then(() => {
      console.log('logged in')
    })
  }).catch(({response: {data}}) => {
    console.log(data)
  })
},
// also save the user data to localstorage as you'd need to access refresh token later

The second way is more complicated, but it puts you in control or each part of the authentication process.

If you wish to use GoTrue, please share the HAR file of you trying to make this request, so we can investigate what could be happening. The HAR file might include sensitive information, so please share it privately.

hi,

thank you for your reply. In the response header is no cookie set
image

I have send you the HAR file.

Big thank you for your time :wink:

hi there, can you post the HAR file somewhere where we can all see it please?

have you access to the files in my app on netlify? So I can upload it with my project.

Because hrishikesh said it could contain sensitive data… Sharing in a pm was not possible because it was too big to copy and paste into the text box and file types other than images is not allowed, like .zip or .txt

Hey @gregor,

Sorry I was off for my weekend.

Yes, that file could definitely contain sensitive data. I’ve got your HAR file and we’ll check it from our end and let you know.

Hey @gregor,

I checked the file, but it doesn’t seem to contain any request made to https://site.netlify.app/.netlify/identity. Did you try to trigger a login when recording the HAR file?

facepalm no forgott it just logged the loading of the page…

have done it now with login, you can use the same url from the pm

1 Like

Hey @gregor,

Thanks for the credentials. I was able to figure the issue. In your GoTrue config here:

…you’ve set the APIUrl as your Netlify subdomain (foo.netlify.app) and thus, GoTrue is sending a cookie for foo.netlify.app domain. So this works fine when you’re accessing your website from your Netlify subdomain, however, it doesn’t work on your custom domain as the cookie’s domain doesn’t match the request domain. If you change the API URL to your custom domain, that should work.

2 Likes

Thanks, I would never have figured that out on my own.

So thats also the reason why it doesn’t work with localhost?
And my custom should be https://www.mydomain.com/.netlify/identity ?

You can always find the correct endpoint in the Identity Settings. But, I guess, for it to work everywhere, you could set it to:

APIUrl: `${location.origin}/.netlify/identity`

That won’t work in localhost, but should work on your prod site regardless of which URL it’s being accessed from. For localhost, you could set some conditions and possibly set your production URL in there.