Gated content not working in Chrome (or Chredge)

[jonsully]

@slim

Oh, wow. I realise now this is way more complex than I thought

You and me both

@slim

My guess is the cookie is used for the gating

Right - and only for the gating. The cookie level is fully separate from the javascript level. The javascript level just kicks off the request that comes back with the cookie. Once the cookie’s in, it no longer matters what the javascript level does; the cookie is in. All things involving role-gating with the _redirects file come from the cookie, not the javascript. We have to think of these two layers as separate and understand how they interact independently (which is tricky)

@slim

From what say this cookie token is managed completley separately from the ID token used in login? That is no doubt the source of so much confusion.

Exactly.

@slim

Also cookies have lifetimes separate from cookie “exp”,

Yes I agree - the JWT/Javascript layer having a different expiration timer than the cookie is indeed another layer to add to the confusion… BUT I should mention that the netlify-identity-widget sets up the cookie request to have no expiration, and stores the JWT in localstorage so in essence, both have an infinite expiration - at least that matches up. When you log in, both are set to never expire. Since cookies and localstorage both persist, even across a browser restart, they’re effectively set until you log out (logging out removes both the localstorage and the response from the /logout endpoint destroys the cookie)

So luckily, the cookie and JWT timers should always be in sync. At least one thing matches

@slim

Plus the cookie is associate with a specific URL - the main deployment only - even more problems.

Yeah. I think that’s your main issue. Again, my workaround won’t work when using the netlify-identity-widget so I’m not really sure how to fix that for you It’s worth clarifying too - the cookie is associated to the primary domain only, but only ever actually even gets set when you’re on the primary domain. Meaning that _redirects will never work locally or on a preview deploy, because the cookie will never be set correctly on those domains (localhost and preview-deploy-x–.netlify.app)

@slim

On a side issue, as suggested in the docs I started using the id token in the Authorizatin header for endpoints provided by Functions and to take advantage of the access token info in the function. What’s not clear yet till I experiment is if the system treats the id token as an access token and manages access or if we have to call the netlify API and do the checks ourselves. For now I’m not too bothered. The reason I say it’s an id token and NOT an access token is it comes through login and doesn’t have “aud” set. Anyway. moving on as this is a confusing topic …

Combining Functions & Identity is a topic I wrote a significant amount on in this other thread - combining the two makes for a really powerful experience but it’s worth understanding the workflow. Give that a read feel free to post in that thread if you have questions pertaining to that topic as well.

Sending the Authorization header to a Function occurs at the Javascript level and doesn’t involve the cookies at all, so that should actually work in any environment since all of the environments correctly produce JWTs for Javascript, it’s the cookie stuff that fails when running not on the primary domain.

@slim

I assumed everyhting worked the same on a preview as main - it seems that is NOT true for gating.

I fully agree. Specifically for role-gating _redirects, there are issues running on non-main.