Identity redirects lag

site: twdocs.bitbucket.io

I have authentication on my site implemented with redirects based on Identity user roles.

Recently I noticed that sometimes, after logging in (and receiving the confirmation from Identity widget that I have indeed logged in as … ) I am still redirected as if I wasn’t logged in. This changes only after a couple of minutes when I am finally able to see the contents as intended.

The last time I noticed this issue was around 15 minutes ago.

I’d like to know what can be done to mitigate this.

Oh, great! Now it’s not even working anymore, which is surprising as I didn’t have changed anything in the site code for the last couple of days.

When anyone tries to log in, the following is displayed:
image

The mystery is that I didn’t create any settings file for identity and always used the settings on Netlify UI itself. Moreover, I don’t find any mention of this path (/.netlify/identity) in your docs.

Also, the redirects have stopped working at all. Now anyone can visit any part of the site regardless if they are logged in or not.

UPDATE. Somehow it resolved itself and Identity works again. But the redirect lag after login is still actual.
I don’t think its a great user experience to log in, get a confirmation that you are logged in and then keep refreshing the page for a couple of minutes to be finally able to view the content.

Today I have encountered the same issue (just right now). I am able to log in via Netlify (in the browser console I see the user object and token obtained). However, when trying to access content area that should be accessible to registered users, I am still redirected to the main page.

In the netlify.toml I have the following (which usually works):

[[redirects]]
from = "/dev/*"
force = true
status = 200
conditions = {Role = ["user"]}

[[redirects]]
from = "/userdoc/*"
force = true
status = 200
conditions = {Role = ["user"]}

[[redirects]]
from = "/dev/*"
to = "/"
force = true
status = 302

[[redirects]]
from = "/userdoc/*"
to = "/"
force = true
status = 302

After a couple of minutes it starts working as intended, but I guess our visitors will not be happy to wait until it allows them to access the site. I will be grateful for any advice what can be done about this. It doesn’t look as something I can control on my side, but I may be wrong (since I already was a couple of times).

I think we had some problem around the time you wrote in with role based reidrects like this - we also saw some odd behavior on an internal site.

Does the “lag” persist even now?

If so, could you send us the x-nf-request-id of such a “deploy completed, but changed rules are not in effect” request? This article explains more about what we’ll need to troubleshoot: [Support Guide] Netlify Support asked for the 'x-nf-request-id' header? What is it and how do I find it?

Hi, thank you for your reply. The problem with this issue is that it’s not really easy to reproduce and I can’t be sure when it happens the next time. It worked for two or three days flawlessly, then (when I wrote my last message) this happened again yesterday. Today it again works without any issues.

However, right now I am almost the only person testing and using the site, so I am a bit nervous about what will happen when we will start adding users in bulk to switch from the old documentation site.

I have read the article you sent me. As the issue happened yesterday, as far as I understand, there is no chance to find the headers for that time. I will save the x-nf-requrest-id the next time this problem emerges. If I can do anything else to speed up the process, please let me know.

It seems that the problem persists for our site. Surprisingly, I was properly redirected to one content section and wasn’t - to the other one.

The x-nf-request-id header I managed to find is the following: 764f556d-e183-4914-a063-8b701bbd4aa7
I am, however, not sure I have selected the proper request, as I don’t know which request should I look for in case of redirects made by netlify. From the available at the console at the moment I tried to access the content section I have issues with, the only one making sense was the one named netlify-identity-widget.js

Same happened today, I was trying to log in from my home PC.

This time I managed to find the header for the dev/ request, that was redirected with code 302.
Again, I was successfully logged in at the moment I tried to access that part of the site.

x-nf-request-id:
e88538b3-387d-4316-ac44-c116cd3bcd21

Hope this helps. Also hope this will be solved soon.

Hey @dcki ,

Thanks for your patience! I can’t see anything blindingly obvious but what I have done is purged the CDN cache for your site, just in case there’s anything awry there.

As for how our RBAC cookies work, I can’t add any more to what @jonsully has already contributed in this thread but what I suspect is that your cookie is lapsing after 1 hour, as per design (but also, recognisably, perhaps undesirably).

1 Like

The classic “Ah it’s been an hour so the JWT is technically expired BUT also technically by having it at all, you’ve still proven your authentication” problem :stuck_out_tongue: A favorite indeed.

1 Like

I’m not sure I understand your answer. So, is the problem on my side?

If the issue is an expired cookie with the proper role but an old auth token - I think, the problem would be that the restricted content is still accessible. But, as you can see from my posts above, the situation is quite the contrary - having a brand new auth token doesn’t get me where it should.

Thank you for purging the CDN cache for me. Just in case - is there any switch for this in the Netlify admin panel so that I could do that on my own?

From where I am it looks more like “Oh, you have obtained a fresh auth token? Good for you, but still I won’t let you in just because I can” problem.

The most painfult part for me is that I don’t see any way to influence this other than ask Netlify for support.

From my understanding of this service, this is simply how it works today. I think Jon has spent a lot of time working on methods to circumvent the one hour expiry but I won’t speak for them!

1 Like