Password makes my JS not load (Cached)

Support
1

Hi,

None of my JS are loaded when password protecting my Gatsby JS website. I think it’s due to everything being cached on first load and trying to load the password protected page instead of the actual JS.

How can I solve this problem ?

2

Hi @a_zili, can you share the site URL? Also how are you password protecting it? Are you using basic auth? site-wide password? JWT role based auth? The more details you provide, the better. Thanks.

3

Was there a solution to this? We believe we’re having a similar issue which we’ve submitted a support ticket (16588) regarding. Thanks!

4

In the end support acknowledged there was a bug but not a priority to fix so instead of using netlify password we used auth via http

5

Hi, @mtrueblood, the issue here is that the custom headers (with Cache-Control: max-age=# settings) are being sent when the site wide password protection is enabled.

This has the side effect of caching the 401 responses for certain assets on Safari which is the root cause of this issue. Why it doesn’t affect the second tab in Safari, that is a Safari mystery which I do not know the reason for.

We do have an open issue tracking this behavior. I’ve cross-linked this topic with the same issue mentioned by @a_zili and we’ll update this topic here in community if/when the issue is resolved.

Also, I know of no workaround for this. If you clear the cached pages, it also clears the cached site wide password and then the cycle repeats itself. Of the major browsers, only Safari appears to be affected by this behavior.

If there are other questions about this, please let us know.

8

Hi Luke.

Thanks for your reply - appreciate your help on this.

(I’ve also replied to the support ticket with a version of the following, but wanted to put the general details here just in case someone else lands here…)

We were experiencing this issue long before adding custom headers to our gatsby-config.js file. We decided to add custom headers only a few days ago, thinking that might help remedy the issue. We’ve been debugging this issue ever since we’ve enabled Netliffy Password protection. When adding custom headers didn’t fix the issue, that’s when we reached out with a support ticket and subsequently came across this post.

We have just removed custom headers from our gatsby-config.js file and triggered a new build. We’re still experiencing the issue even without custom headers. We’ve triggered cache cleaning from the Netlify console and opened a fresh instance of Safari, with preview build link.

We also have the exact same code base setup and deployed on a different Netlify site WITHOUT Netlify Password protection (also without custom headers) and the issue does not exist there.

9

Hi, @mtrueblood, I also replied to the email/ticket about this. We’re happy to keep troubleshooting there and we’ll update this community topic with what we discover (and you should also certainly feel free add updates here as well).

If we can reproduce the issue without custom headers that would be new and I’ll update the existing issue (or file a new issue) to include this new behavior. We want to learn more about exactly what is required to trigger this behavior with Netlify site-wide passwords and Safari - especially reproducing the issue without custom header.

10

Hi,

Not sure if I should be replying to this thread or the email / ticket mentioned in other replies - I’m seeing the same behaviour with multiple Netlify sites, some Gatsby some not, in Chrome (Mac). When accessing the site, I’m prompted for the basic auth password, but the app doesn’t load (it appears to ‘hang’). When I refresh the page it loads fine. The site is still usable, and the basic authentication works, but it’s frustrating to have to refresh each time.

Any update on this would be much appreciated :slight_smile:

11

Hey @andy-carrell, could you please share your Netlify URL so we can take a closer look?

12

Hi @jen - of course, see here Netlify App

Can be reproduced across a few other sites we run

15

Hey @andy-carrell, we took a closer look at this and the behavior you’re seeing seems to be intended (though understandably frustrating). A few notes on password-protected sites:

  • when you enter your site password, we set a cookie saying that you’re authorized to get your site assets. If the cookie hasn’t been set by the time you request your site assets, you’ll get a 401 http status for that asset. This is probably what you’re running into. Once the cookie is set, though, everything should work fine since you’re now authorized. There are many things you could try in order to avoid having to refresh- only requesting assets once you have the auth cookie, etc.
  • every asset behind a password-protected site is password-protected, so if you were ever requesting one of those assets from another site, the requesting site would need to be authenticated.

Hope this is helpful! Please let us know if we can answer any other questions on this.

1 Like
16

Hi @jen thanks for getting back to me on this - this is really helpful.

Obviously it’s not the ideal experience, but it’s only really a pain point the first time you visit a site, although this comes up a lot when using pull request previews.

Good to know it’s expected behaviour, and not necessarily something to do with our setup. Thanks for your help :slight_smile:

1 Like
17

This may not be super helpful, but wanted to add some steps to “Turn on” and “Turn off” this issue. This has helped me for debugging as it’s been a surefire way to drop in and out of the issue where simply clearing the cache wasnt working before (I believe there is an element of service worker magic going on here especially for anyone using a typical Gatsby setup, which relies on them).

Steps to Experience the Issue

  • Turn on password protection using the Netlify Global Password option in a Netlify site’s dashboard at Site Settings -> Access Control -> Password / JWT Token.
  • Delete existing cache AND service worker for the site. Open Safari and go to Safari -> Preferences in the navigation bar, and then click “Manage Website Data” in the “Privacy” tab.
  • Search for Netlify, select netlify.app and click “Remove”.
  • Open a new tab in Safari with Safari’s dev tools panel open.
  • In the same tab, load your password protected Netlify site.
  • Note a number of 401 errors prior to being shown the Netlify password form.
  • Enter password and proceed.
  • Note site does not properly or fully load due to number of failed but cached asset requests (the aforementioned 401’s).

Steps to Turn the Issue Back Off (Turn off Password Protection).

  • Turn off password protection using the Netlify Global Password option in a Netlify site’s dashboard at Site Settings -> Access Control -> Password / JWT Token.
  • Delete existing cache AND service worker for the site. Open Safari and go to Safari -> Preferences in the navigation bar, and then click “Manage Website Data” in the “Privacy” tab.
  • Search for Netlify, select netlify.app and click “Remove”.
  • Open a new tab in Safari with Safari’s dev tools panel open.
  • In the same tab, load your password protected Netlify site.
  • Enter password and proceed.
  • The site should now load fine where it did not before turning off the password.
1 Like
18

This is great, many thanks for the step-by-step on/off instructions :raised_hands:

19

Man, took me ages to find this issue. Still experiencing this.

I think this same issue is happening on iOS mobile, both Safari, and Chrome? Safari mobile makes sense, but chrome mobile was surprising - I think it’s because it uses the same webkit engine.

20

Ok, so figured out some more stuff.

So if I loaded up my password protected gatsby site in safari, you get a network tab with a whole bunch of 401s, including all my javascript bundles. Erroring because the password cookie hasn’t been sent yet. Makes sense.

But why are they loading on the password page? If you look in the html it’s just a super basic page, with no links to these files - where are they coming from?

Digging a bit deeper - if you check the headers from the landing page, turns out there’s a Link header, which preloads a bunch of assets - which will all fail without our lovely password cookie! Culprit found!

Screen Shot 2020-12-08 at 3.14.46 PM
Screen Shot 2020-12-08 at 3.14.46 PM2750×1664 788 KB

Turns out I was using gatsby-plugin-netlify which makes a bunch of headers, including link headers - which are sent when the password page is sent.

You can disable link headers in your gatsby-config.js like this.

module.exports = {
  plugins: [
        {
          resolve: `gatsby-plugin-netlify`,
          options: {
            mergeLinkHeaders: false, 
          },
        },  
    ]
}

That’s good enough for me right now, however it’s bit of a bad solution. As I do actually want pre-loading on production, gotta go fast. And setting this in the source means I can’t change it between Netlify sites, like only have this on the staging sites, but not production.

Not really sure what the best fix would be - but a suggestion for Netlify - maybe make the password protection response’s headers immutable? So you always get a default set?

1 Like
22

Hi @EliotSlevin, welcome to the Netlify Forums!

Right, those header rules will apply even when showing the simple password-protect page as long as the rule matches.

One thing you could try is setting an env var specific to your staging sites and making the change below: mergeLinkHeaders: process.env.GATSBY_IS_PROD. So if that env var is set to false, the preloads will not be set.

Let me know if that works. :slight_smile:

23

Yeah. Using stage env variable is obviously the best way to handle that. Will go the same route. Using this env var all over the place in gatsby config anyway.

1 Like
24

thanks for sharing. Unfortunately i did nearly the same research before reading yours. Heck, i didnt even know what a “link” http header is.

1 Like