We would like to prevent access to any site previews unless authenticated using Netlify Identity.
It’s a statically generated website; so it contains many URL entrpoints.
We would like to prevent access to any site previews unless authenticated using Netlify Identity.
It’s a statically generated website; so it contains many URL entrpoints.
Hi @kruncher
By setting the login role in the JWT payload, you can set the access to a path in your _redirects
to fall through to an unauthorized path.
See this article: Getting Started with JWT and Identity
Hope that gets you what you need.
Hi @talves we are looking to use the Netlify Identity with Google Auth; how does that work with the JWT payload?
With the redirects how can I have it match everything to assign the role?
Hi @kruncher,
Usually, you have to setup roles manually in the UI. You can also do it in serverless functions by using the identity signup event. Only after a role has been set, you can use Role Based Access Control. Role-based access control with JWT | Netlify Docs
How do I define the redirect rule though?
Using the Netlify redirect playground I can’t figure out how to apply the gating to all URLs:
/* 200! Role=member
The site contains many many static .html files for pages. I simply want to prevent access entirely if the role isn’t present on the account. Is there some sort of /**/*
redirect?
Many thanks
Hi @kruncher,
/*
applies to everything in the website. There’s no need for /**/*
. So, with your rule above, you’d essentially allow anyone with the role as member to access the website and everyone without the role would get a 404 page.
I added the following redirect rules:
/* /cy/:splat 302 Role=member Language=cy
/* /en/:splat 302 Role=member
/en/* /en/:splat 200! Role=member
/cy/* /cy/:splat 200! Role=member
/* /login 401!
There are a few issues with this though.
The URL /en/foo
shows a 404 rather than the login page at /login
.
After the user logs in with Google OAuth it redirects them back to the staging deploy context URL rather than the preview URL that was accessed via the deployment preview button in Netlify. Access is granted to the user if they manually navigate to the correct URL again but it’s terrible UX.
That would be expected behaviour. Let me explain why. Netlify Redirects processes the redirects file from top to bottom and stops processing after the first rule is matched. So, in your case /en/*
rule matches the /en/foo
path but it’s gated by RBAC. So you might think, it would go down and use the fallback path of /*
and should match the login path, but it doesn’t. Because the redirects engine has stopped looking for more rules, it’ll now reach 404.
In your case, you’d have to add a separate rule for each gated rule that you add. So your file might look something like:
/* /cy/:splat 302 Role=member Language=cy
/* /en/:splat 302 Role=member
/en/* /en/:splat 200! Role=member
/en/* /login 401!
/cy/* /cy/:splat 200! Role=member
/cy/* /login 401!
/* /login 401!
About the point number 2, I’ll revert with some additional info as I’m not sure if something can be done about it or not.
Thank you this seemed to work nicely.
I was experimenting with adding an event listener netlifyIdentity.on('login', () => location.reload())
which does reload the page but the page continues to show the “login” content rather than the now authorized content.
If I navigate to other pages within the static site; they show as expected. But the original page that triggered the 401 login response shows the login page for quite some time. I thought it might be a cache issue so I added no caching headers to the head of my login page but the problem still persists.
Any thoughts on what that might be caused by?
A guess might be difficult without actually seeing it happen.
The setup is fairly simple. I have the _redirects file as shown above and just a few statically generated .html files. It’s like the content of the login page is being cached (either by the browser or by Netlify) for whatever URL caused that content to appear even after login. It takes a short period of time before a refresh causes the correct content to appear for the page.
There seems to be something weird going on with the cookies/local storage with the Netlify Identity Widget. Deleting and re-logging in over and over again every so often makes the page appear as it should. I’ve tried a range of things including netlifyIdentity.refresh()
and netlifyIdentity.gotrue.currentUser().update()
but those don’t seem to help and often report “Could not read User Update params: EOF”.
Hi @kruncher,
I’m not able to reproduce this unfortunately.
I have setup a basic website with Identity: https://romantic-edison-3bb61d.netlify.app/. Could you try and see if that is going through the expected behaviour according to you? Chances are I didn’t understand you completely.
You can login with the following credentials:
Email: hello@test.com
Password: 12345678
This is the repo: https://github.com/Hrishikesh-K/identity/.
@hrishikesh is there a way for me to send you a direct/private message with the link to our site?
Hi @kruncher,
Sure you can send the link to me via DM. I’ve checked and your account should have DM permissions.
Hi @kruncher,
In the link you shared, I don’t see any role based redirect. The only ones you seem to have are these:
/* /cy/:splat 302 Language=cy
/* /en/:splat 302
But your description there is correct. It kept redirecting for a while and then it settled. Interesting.
The redirects file is this:
/ /cy/ 302 Role=member Language=cy
/ /en/ 302 Role=member
/en/* /en/:splat 200! Role=member
/en/* /login 401!
/cy/* /cy/:splat 200! Role=member
/cy/* /login 401!
/* /login 401!
We are looking at the staging branch not the main one.
Oh yeah, sorry, I looked at the wrong one.
As a probably unrelated aside I also noticed that the cookie is being set on a per page basis rather than using the root path in the cookie.
Hi @kruncher,
What happens when you remove the JS that you have in the body of the page? I do feel it’s that what’s messing up. If it was a server side redirect, the browser would stop redirect after a few times and would throw the error TOO_MANY_REDIRECTS
. But instead the page loads and it’s the JS that then reloads the page is what I believe.
Could you try removing it for now?