提供私人内容：S3签名URL与CloudFront签名URL

Question

I want to have a small website/page which will interact with a web service of mine. I want to restrict access to this page. This page being very small, I don't want to bother with having a separate server for this, so decided to use S3's static website hosting.

The basic idea would be to have a login.html page which will have a login form (take username and password), authenticate with the web service and after successful registration return a signed URL to the private page. This private page will then call the (AJAX/REST) web service for further interaction etc.

I stumbled upon CloudFront's serving private content feature by creating signed URLs or signed cookies. But later on, found that we can have signed S3 URLs also. (Both have URL expiry features.)

What are the differences b/w both (S3 signed URL vs CloudFront signed URL/cookies)?

The page/website would have very little traffic and speed/latency isn't our concern.

My question is: should I stick with CloudFront signed URLs feature or would just S3 suffice?

Also for CloudFront, if let's say I have to do a bugfix/patch in the page, then it doesn't get updated right away once you upload the file to S3. It takes at least 24 hours since it is cached by the edge servers. How do you deal with this?

Anything about this design that I should be aware of? Any security concerns/loopholes?

EDIT: The web service which I have is basically kind of serverless. It is a bunch of AWS Lambda functions and API Gateway in front of those Lambda functions.

Answer 1

I am not sure if this is what you are looking for but I will give it a shot.

I think you want Signed Cookies. The issue (from what I understand only using this method for the past few days) with Signed URLs is that once they are in the wild they keep working unless you set the expire to a very short time. So in theory your user could logout and still use a signed URL to access your content.

If you use the cookie method you can have a call in your code to confirm the user is logged in and if not clear the cookies and Cloudfront will stop serving the content.

You will need to add another behaviour in your distribution to allow access to your signing page etc. (ie when not logged in).

The trick here is to NOT use signed URLs at all. If you do Cloudfront takes precident on the URLs over the cookies. So if you clear the cookies the signed URLs still work.

As for the cache settings you would need to look at fingerprinting ( http://guides.rubyonrails.org/asset_pipeline.html#what-is-fingerprinting-and-why-should-i-care-questionmark for an example). Not sure how you could do this in your scenario but that would do the trick. Change the fingerprint and Cloudfront thinks it a new file and away you go.