The topic of hosting a static site in AWS S3 has been beaten to death. We’ve never written a post on the basics of hosting a site with S3 as you can easily find that somewhere else. However, AWS recently revamped their S3 Console with a new updated UI in May 2017, so let’s complete our series on hosting with S3 and walk through how to host a static site in the new S3 Console UI.

AWS S3 series:

1. Host a Static Website in AWS S3 (this post)
2. Naked domain redirection in S3
3. Host S3 with HTTPs using AWS CloudFront and Certificate Manager
4. Password protect a regular HTTP S3 site by mimicking HTTP Basic Authentication
5. Password protect an HTTPs S3 site

Quick summary of Hosting a Static Website in AWS S3:

1. Create an S3 bucket
2. Set static website hosting
3. Set public read
4. Upload files to S3
5. Set DNS (optional)

This is Part 2 of the 2-part topic on HTTP Basic Authentication with S3 Static Site:

• Part 1: Basic Idea - review the details behind the idea, correct a couple inaccurate info, and examine its limitations
• Part 2: Extend - see how we can extend it further to be generically applicable for any sites (this post)

Extend S3 Basic Authentication

We want to address the 2 limitations mentioned in Part 1, and touch on a couple other ways you can utilize S3 password protection:

1. Allow referenced files to be accessed in a similar way to the Main File main.html
2. Keep index.html as the Main File and use password.html as the Entry File
3. Different passwords redirect to different sections
4. Use CloudFront HTTPS with a password protected S3 site

Updated 05/28/17: updated for S3 new Console UI.
Updated 12/09/16: added complete Sample Code for Section #2.

Hosting a static site with AWS S3 is quite popular. Many of our clients opted to launch their beta or marketing site using S3. We ourselves hosted many demo sites on S3 as well. One of the recurring requests was to password protect a site, especially when it’s a pre-launch, beta, or demo site that should only be available to restricted viewers.

With a regular web hosting service that runs Apache or Nginx, you can easily password protect a site using HTTP Basic Authentication which is formally defined in RFC7617. AWS S3 doesn’t support HTTP Basic Authentication nor has any equivalent feature for it.

All is not lost. Xing Quan has figured out how to password protect an S3 site using a combination of permission setting and file redirection on S3. I was wondering how he got the insights to cleverly utilize those S3 features to achieve the effect of password protection. It turned out that Xing Quan was a PM at AWS S3 according to his profile.

An alternative is s3auth, a proxy service provided by Yegor Bugayenko. It basically sits in front of your S3 bucket and implements the native HTTP Basic Auth while passing data from the S3 bucket back to end-user browsers. Kudos to Yegor Bugayenko for providing the service for free. It doesn’t cost you anything to use it. However there are legal, privacy, security, and performance concerns that make it unsuitable for medium/large sites and corporate clients.

Xing Quan’s solution is more attractive because it can be implemented purely on S3 and can also be extended to play well with other AWS services like CloudFront. Most of our clients wanted to be self-contained within AWS to avoid corporate concerns mentioned above.

Huge credit goes to Xing Quan for the technique. Still, there are some limitations that makes it not applicable for all websites. We’ll look at this in 2 parts:

• Part 1: Basic Idea - review the details behind the idea, correct a couple inaccurate info, and examine its limitations
• Part 2: Extend - see how we can extend it further to be generically applicable for any sites

Updated 5/26/17: updated for S3 new Console UI.

The bash version that comes with Mac OS Sierra is still the old v3 dated back in 2007.

# Mac Sierra
$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.12.4
BuildVersion:	16E195

# Bash version that comes with Mac OS
$ which bash; bash --version
/bin/bash
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin16)
Copyright (C) 2007 Free Software Foundation, Inc.

GNU bash v4 has been introduced since 2009 that includes many new features, e.g. one of which is the shell option globstar ** that we used to recursively traverse directory hierarchy.

At some point you will have more than 1 workstation that you work on, say a main desktop and an on-the-go laptop. Some may have a few, e.g. a desktop and laptop at work, and a personal computer at home. I myself have a MacBook Pro and an iMac that I switch between every other day.

I need a reliable method to sync my workspace. There are a few good options:

• git
• rsync
• File synchronization/sharing services (iCloud, Google Drive, Microsoft OneDrive, Dropbox, Box, etc.)

They all have their pros and cons, but I’d recommend only Dropbox specifically for developers due to its sync performance.