Hey people!
Is there a way to bypass/satisfy the global password protection of a netlify site? Otherwise, all proxied requests (e.g. an internal API behind /api/…) will fail as the password protection will be present during the requests from an SPA application.
An idea would be a custom header with a secret/token (or even the password?)
Hi @manniL,
I don’t see a way to do that. You would have more flexibility if you used role based authentication since you’d get the power of our redirects engine there. However you have to be on the Business team or a custom plan for that. Just to be clear, are you using the site-wide password or the _headers file password? Is the user already authenticated and on the page, and requests are still failing?
Hey @futuregerald 
I’ve tried both, using Basic-Auth with _headers and a site-wide password and will elaborate on the problems I’ve noticed with both approaches.
Site-wide password:
Works fine for the front-end, but all requests to the API, which is available through a proxied api route, will fail while the site is being generated (using Nuxt.js here).
Basic-auth via _headers: Works mostly fine but clashes with JWT Auth with the API as the Authorization header is used for both.
The password protection is only necessary for the dev and staging builds, so I’m not sure if roles would help here.
Two “solutions” that’d solve the issue:
You could certainly pass the Authorization header that Basic-Auth creates. It isn’t something you can get at build time, so you’d have to get it at browse time if you were going to manually apply it to some request.
The browser usually does that automatically if you make the appropriate calls (ones that preserve the site based request headers from the initial request post-auth) and the calls are to the same domain.
You could certainly pass the Authorization header that Basic-Auth creates. It isn’t something you can get at build time, so you’d have to get it at browse time if you were going to manually apply it to some request.
The problem is that I already use the Authorization header to pass the user’s JWT token to the API, which means it’d be overridden and the “logged-in requests” would all fail.
Hi everybody.
Has anyone found a solution to this problem?
Which problem are you talking about? We have not tried to get JWT + global password working together; that is not something we’re trying to solve.
If you’re talking about how to use the password auth, I did explain just above the best “solution” - to pass the auth header on (it’s a workaround; you should use basic auth instead of the global password to access reliably in a programmatic way that won’t time out)