How to password protect Hugo site / SSG site?

Question

I would like to build a Hugo site that can be:

• password protected (specific pages, not the entire site)
• be hosted with a private repo that is free or very low cost
• can be edited using a CMS interface (i.e. Forestry.io)

I know Bitbucket allows free private repos, but I don't understand how to password protect certain pages. I currently have a Github page set up, but the repo is public. I know I can pay for a private repo on Github, but still don't understand how to do the password protection of static site pages.

I've read that Netlify offers a password protection feature, but it would require me to pay $99/month.

I have considered Wordpress but if at all possible, I would really like to use an SSG. I am a beginner but am practicing CLI and have been somewhat successful.

Please let me know what you recommend. Thanks!

Lahomalahore

Unfortunately there is no un-opinionated answer to your question. There are ways to accomplish what you want, but not a decisive answer based on the question that is too broad. – Claytor

netlify's password protection costs $45/mo for as many sites as you would like to protect. – Mump

Answer 1

If you are running NGINX in front of a hugo server which you control, take a look at vouch: https://github.com/vouch/vouch-proxy.

With a little bit of setup and configuration file work, you can get authentication based on Gmail, GitHub or many other identity providers. That is not only do you get get protection of your static site, but you don't have to manage the user accounts/passwords yourself. For example, you can list the allowed users by Gmail account or GitHub username.

Anubis

Vouch looks very interesting, thanks for sharing – Abyssal

Answer 2

It's been a while since the question was asked, but I didn't see an answer that covers this method, so here goes. One way to handle authentication for any static site, without having to change the site itself, is to use what I'll summarize as 'a CDN + serverless functions' to check for authentication and serve pages. Here's a diagram:

Already Authenticated...
[Browser] --> [CDN] --> [Auth Verified] --> [Serve Page]
Not Authenticated...
[Browser] --> [CDN] --> [Redirect to Login]
Successful Login...
[Give Cookie] --> [Redirect to Original Request]

This is initially more complicated than hosting the site on a single server with Apache or NGINX, because the request is passed between different cloud services, and you have to properly configure those services. But it's a flexible way of doing things, and once it's set up, you don't have an OS and various server software to worry about maintaining. Plus, compared to what people are paying for the 'done for you' solutions that may still be non-trivial to configure, it is cheaper. A serverless login function costs nothing while people aren't logging in, and one Hugo site in an S3 bucket is pennies per month.

So here is how I would do this with AWS, or other IaaS/PaaS providers with similar functionality. With AWS I would drop the Hugo site in an s3 bucket. Only Cloudfront (their CDN) would be allowed to read/list the bucket (bucket policy), so Cloudfront would act as the server.

Cloudfront, in turn, allows pattern matching 'behaviors' to forward certain paths / patterns to Lambda (serverless) functions or Cloudfront's own javascript functions. So favicon.ico and anything in /public can skip authentication, for example, while anything else in the site (Default * pattern) would require an authenticated user. Or, if you just wanted to protect a few pages, you could list those pages or their directory as patterns that forward to your authentication-checker function, and default to no authentication.

In the simplest case, your function checks for a specific username and password using Basic Authentication. Of course, you'll probably want to do better than that.

To make it business friendly, the serverless function checks against an identity broker/pool such as Cognito (the AWS one) or Auth0, etc. That way you can manage many users with relative ease, and integrate with an identity provider such as Microsoft, Google, GitHub, Azure AD if need be. If users need to reset passwords, or enable MFA, etc, they can do that with a certain amount of independence.

AWS provides a stack script and an article that sets up a proof of concept for this model.

Once you have the example up, modifying it for your purposes and dropping your Hugo site into a protected s3 bucket is not too hard, as long as you have some familiarity with AWS.

Getraer

Answer 3

Go Hugo will help you generate static pages.
How those pages are served is entirely up to you, meaning Hugo knows nothing about page protection. Only page generation.

That means you need to generate a way for a site to have some form of authentication.

From 2018:

See "How To Password Protect A Hugo Site", which explains how to add a login page to a Hugo site that’s hosted on Bitbucket / Aerobatic, by Jason Gowans in 2017.
Jason mentions:

It uses Aerobatic’s HTTP basic-auth plugin.
You can add the built-in browser dialog version for free, or the pretty login page option with paid plans.

That plugin is now (2018) deprecated, and replaced with the Password protect plugin.
It does support the protection of a sub-directory:

plugins:
  - name: password-protect
    path: /private
    options:
      password: $SITE_PASSWORD

Update 2021: as noted by aretor in the comments, aerobatic will cease its operations on October 31st.
Netlify would be the current alternative.

Wanitawanneeickel

Thanks, but it looks like Aerobatic charges $15/month. Are there any other lower priced options? – Lahomalahore

@Lahomalahore Not sure: maybe one of those: alternativeto.net/software/aerobatic (not GitHub Pages though) – Wanitawanneeickel

Please, note that aerobatic will cease its operations on October 31st. – Professionalize

@Professionalize Thank you for this: I have edited the answer to include your comment. – Wanitawanneeickel

Answer 4

Since Hugo is a static site generator, you can't do this directly.

However, it can easily be done via the web server engine. So you need to choose a service that supports access to the web server configuration and allows - or has already installed - a plugin such as NGINX auth_request.

There are plenty of low host hosting and VPS solutions that will let you do this.

Stubblefield

Answer 5

If you have an NGINX server in front of your hugo site, you can also use https://github.com/aocks/ox_jwt to restrict it to users who provide the correct JSON Web Token (JWT) in either the URL or a browser cookie.

Anubis

Answer 6

This is more an architectural problem.

If you know which email addresses have access. You can setup Cloudflare one-time PIN login

Auction