Netlify CMS authorization redirect loop

[Destroy666x]

Relevant information

https://tech.boldare.com/admin/?no-cache=1#/ - enter, try to register with FB/GH, you end up with a redirect loop and 404s for /.netlify/identity/authorize in console. I'm not sure if it's a problem of Gatsby or Netlify. But before upgrading most of libraries it was fine, so my main suspect is Gatsby.

Environment (if relevant)

Netlify.

  System:
    OS: Linux 4.15 Ubuntu 18.04.1 LTS (Bionic Beaver)
    CPU: x64 Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz
    Shell: 4.4.19 - /bin/bash
  Binaries:
    Node: 9.10.1 - /usr/local/bin/node
    Yarn: 1.12.1 - /usr/bin/yarn
  Browsers:
    Chrome: 70.0.3538.77
    Firefox: 63.0.1
  npmPackages:
    gatsby: ^2.0.17 => 2.0.35 
    gatsby-image: ^2.0.13 => 2.0.19 
    gatsby-plugin-algolia: ^0.2.0 => 0.2.0 
    gatsby-plugin-catch-links: ^2.0.3 => 2.0.3 
    gatsby-plugin-favicon: ^3.1.4 => 3.1.4 
    gatsby-plugin-feed: ^2.0.7 => 2.0.9 
    gatsby-plugin-google-analytics: ^2.0.6 => 2.0.7 
    gatsby-plugin-manifest: ^2.0.4 => 2.0.7 
    gatsby-plugin-netlify: ^2.0.2 => 2.0.3 
    gatsby-plugin-netlify-cms: ^3.0.4 => 3.0.5 
    gatsby-plugin-offline: ^2.0.5 => 2.0.10 
    gatsby-plugin-react-helmet: ^3.0.0 => 3.0.1 
    gatsby-plugin-react-svg: ^2.0.0 => 2.0.0 
    gatsby-plugin-sharp: ^2.0.5 => 2.0.10 
    gatsby-plugin-sitemap: ^2.0.1 => 2.0.2 
    gatsby-remark-copy-linked-files: ^2.0.5 => 2.0.5 
    gatsby-remark-external-links: ^0.0.4 => 0.0.4 
    gatsby-remark-images: ^2.0.3 => 2.0.5 
    gatsby-remark-prismjs: ^3.0.1 => 3.0.3 
    gatsby-remark-responsive-iframe: ^2.0.5 => 2.0.5 
    gatsby-remark-smartypants: ^2.0.5 => 2.0.5 
    gatsby-source-filesystem: ^2.0.1 => 2.0.1 
    gatsby-transformer-remark: ^2.1.6 => 2.1.11 
    gatsby-transformer-sharp: ^2.1.3 => 2.1.7 

File contents (if changed)

https://github.com/xsolve-pl/boldare-tech

[kakadiadarpan]

@erquhart any insights regarding this?

[KyleAMathews]

/cc @DSchau @davidbailey00

[vtenfys]

This is probably as a result of the offline plugin - @DSchau and I recently decided it's best to simplify it due to the problems people are facing.

I was planning on starting the rework next week, but given the problems some people are still facing like your issue, I'll try to get this done sooner - hopefully by the end of the week.

[erquhart]

More likely to be #9269 (although triggered by the offline plugin query string in this case). That PR either needs to be rolled back or updated to account for other entities interacting with the location. My knee jerk is roll it back.

Related to #9584.

[pieh]

@Destroy666x please update to gatsby-plugin-netlify-cms@3.0.6 and let us know if issue is fixed for You

[Destroy666x]

Doesn't seem to still, tested in incognito. Only non-external way of registering an account works. I also contacted Netlify support to make sure the issue isn't on their side.

[erquhart]

Any chance you're also using the offline plugin?

[Destroy666x]

Yes and I just updated .10 to .12 since I see that came out yesterday, I guess I'll need to set up some kind of notifications for the most "sensitive" Gatsby parts 😛. Since the changes seem to be very frequent.

But updating didn't help, you basically need to be in a session with service workers disabled in the console or it doesn't work. Also, not sure why Netlify CMS is affected by the offline plugin in the first place, are some parts supposed to work offline? I see there's no-cache parameter that seems to not work properly

[Destroy666x]

And the fix seems to be straightforward - navigateFallbackBlacklist by default for some reason assumes that the URL ends with the parameter, but that's quite a big assumption. After removing $ it looks to be working (but unfortunately still requires unregistering the worker for the last time).

[vtenfys]

navigateFallbackBlacklist by default for some reason assumes that the URL ends with the parameter, but that's quite a big assumption

Oops, another edge case I forgot to consider - Gatsby always writes no-cache=1 at the end of the URL so it's reasonable to expect it to be last, but if a page appends something else afterwards then that might not always be the case. Thanks for spotting this!

Just to reiterate on my previous point that we're planning to remove the no-cache URL handling entirely, in favour of a dynamic whitelist - this should fix a lot of existing edge cases such as this one. Hopefully should be done by the end of next week (previously I said at the end of this week, but that might not be possible given limited time I have this week).

[Destroy666x]

I see. Yes, there can be a lot of edge cases for that, so replacing it with a different solution would be better.

I hope to see the plugin for optionally unregistering old SW for users that have, let's say, some kind of localstorage lastVisitVersion or whatever value. Should I create a different issue for that or do you want to with a better description?