Add password protection for non-published deploys

Features
, , , , ,
#1

Hi there,

I looked around and I couldn’t find any option to solve what we need with existing features.

The use-case is simple and for our client pretty important. We do want to be able to password-protect everything but the published site. All deploy and branch previews. I know of the option to set basic authentication through headers, but since we are talking atomic deploys, I could password protect all the previews, but then I could not restore those deploys.

Here is how we use Netlify:

We built an interface, where the client can use the API to trigger a build without it auto-publishing. Then we provide the preview link and if the changes have been successfully reviewed, the client can publish this specific deploy (restore deploy in the API).

I believe this is also the power of atomic deploys, since we can rely on a specific version of the build that one wants to publish. Yet, we want to make sure any deploy that is not published, is password protected. Even though, deploy previews are not indexed (or shouldn’t be), there is still a chance of this specific url leaking. It’s a high profile customer, that is dependent on certain press-releases to be only published at a specific time and date.

Preferably there would be a setting in Netlify (a simple checkbox/radio), that allows us to define how the already available Password Protection (Visitor access) feature is applied.

While we need only on of those, I can think of the following scenarios:

  • All
  • All, but published site
  • Only Preview Deploys
  • Only Branch Deploys
  • Specific Branches

We are running on a business plan if that helps.

Kindest regards

#2

You’re not wrong; there is no way to do this on our service. You could simulate it by:

  • password protecting the dev site which builds all commits
  • use the dev site to do all your validation
  • when ready to publish, create a new site and deploy to it. Yes, every time you want to publish a prod deploy. The only way to delete deploys is to delete the site.

This is super inelegant so I would be inclined to work with your client on what their actual use case is - I understand your proposed solution to it, but perhaps their use case is more like “make sure no DEV deploys are accessible”? That is a lot easier to make work here.

#3

Hey @fool for whatever reason some of the words here sparked an idea in me - since _redirects and _headers files get applied per deploy, would it be possible to build a Build Plugin that runs early on in the build process and grabs the context, then configures basic auth via _headers for non-prod contexts?

Might be a fun build, not totally sure if it would work though

–
Jon

#4

@fool thanks for the answer.

As mentioned above, the use-case is that we want to make sure, that the previewed deploy is also exactly the one that would get published. Therefore setting up an extra dev site for it wouldn’t make sense, since we would loose the benefits of an atomic build. We wanna be 100% sure we can publish a build that has been reviewed before.

I wonder what the architecture at Netlify is, that would make this difficult. How is the current Basic Auth set for the whole domain?

@jonsully surely this should work, as some people already suggested in the forum, one can add Basic Authentication through headers for certain deploys. Yet this wouldn’t solve our problem, since we would like to be able to publish this specific deploy. That way this deploy would always be password protected and we would need to rebuilt again.

#5

Hey @henry1 - my apologies, I don’t think I fully read your first post. You had already mentioned the headers auth idea so my add was needless.

I agree with @fool that this specific set of needs would either be quite painful or just not work well on the platform. That said, I think (as @fool perhaps eluded to) if the requirement of publishing the exact set of assets that resulted from a particular commit build was relaxed, you could have a pretty easy workflow. I guess this just brings the question, is it alright if the same commit hash with the same environment variables builds on two different (identical) containers?

–
Jon

#6

Hey @jonsully,

it is no option for our client to relax the need for a specify deploy to be published.

The problem is that if between the time of creating the last deploy (protected) and then a deploy that should get published, there might already be new content on the site, that someone has created for a future release. So this would open up a whole lot of problems for the releases.

@fool is there anything we can do here? Is this something that could get on the roadmap? I feel like it would solve the password protection problem for a lot of people with multiple use-cases.