Weird behavior by netlify-identity-widget and role based access control / _redirects

Thanks @bkeepers . I hope this can be solved and benefit us and the rest of the community.

1 Like

Dear All,

I think I have been able to solve the problems (partly) I have been facing here. The fixes are 2 fold, partly in the redirect, and partly in the identity token management.

  • I added a script to check if the token has expired, and if so, then netlify is to refresh the token and give a suitable message in the console.
if (user) {
    const timeCheck =
      netlifyIdentity.currentUser().token.expires_at > new Date().getTime() ? false : true;
    if (timeCheck) {
      netlifyIdentity.refresh(); //.then((jwt)=>console.log(jwt))
      console.log('Welcome', user.user_metadata.full_name);
    }
}
  • If someone is not signed in on a page which needs authentication, a simple script can be added for the netlify widget to open up.
if (user) {
...
} else {
   netlifyIdentity.open();
}
  • Next I created 3 redirect rules
/houses-for-sale/* 200! Role=customer
/houses-for-sale/ /houses-for-sale/ 200! Role=customer
/houses-for-sale/* /no-access/ 401!

I thought rule 2 in the redirects was redundant but it just behaved better than without it.

In summary,

  • I have a clean headers file
  • A good routing in the _redirects file
  • a decent on-page script that refreshes tokens or pops up the widget in case you are not logged in.
  • a refresh button which you should press ideally 1-2 mins after a page loads. I know it is not intuitive, thus I marked the button to be refreshed only after 2 mins explicitly though one could add a js script to activate the button after 120 seconds.

The refresh behaviour is probably such because of the caching and probably the script below could do some more magic!

I have updated the demo repository for my own purposes when I make apps using identity for the future and I hope it is also helpful for anyone who may use it in the future.

Demo Repo: https://github.com/sachinsancheti1/netlify-identity-redirect-check
live demo: https://nifty-payne-1700e9.netlify.app/

1 Like

Thanks for chiming in and sharing this, @sachinsancheti1! We appreciate it.

I have the same issue. After setting the nf_jwt cookie, the gated page that caused a 401 redirect can only be accessed after 10 minutes have passed. Other gated pages can be accessed immediately. This must be a caching issue.

Is there a solution on Netlify’s end?

This is the same issue that I am having… it certainly seems to be an issue with Netlify’s widget.

We are considering using Netlify for a fairly big project; but gated content is an essential feature for us.

Hi all,

So i have been using the application with the above configuration I had suggested earlier. This is my observations.

  • If authorized user lands on a gated page before the token is refreshed, say because someone shared the gated link via email / chat etc. and the end use just opened it, THAT ONE PAGE will be blocked out for a few minutes while the other pages seem to work fine
  • If authorized navigated to another gate page correctly and then came back to the original link, the original link would not work at times.

While most desktop users may not find it difficult, hard refreshing and re-opening a page after navigating are not very intuitive procedures followed on a mobile app.

Hard refreshing doesn’t seem to help refresh the page that was used to login for me. I have to wait for a while and sometimes it doesn’t ever refresh whilst all other pages show as expected. In a similar way; when the session is logged out, other tabs continue to show authorized content for a while (with refreshes).

I have reported this as an issue here - There is an issue with gated content · Issue #479 · netlify/netlify-identity-widget · GitHub

If this strange caching issue cannot be resolved then this is a deal breaker for us with Netlify and we would potentially adopt Netlify in quite a big way.

Hey there!

We’ll continue the conversation with you, @kruncher, in your topic!

1 Like

Dear All,

Lately I have found that after the first visit to a page and refreshing the page, the authentication takes the right values without any additional requirement of logging in or logging out. I would mark this as a resolved issue from my side as it fits the need of my use case as expected. With this I would like to close this topic of discussion.

1 Like