Quest for Immutable Static Files Hosting | Hacker News Reader

Quest for Immutable Static Files Hosting

avodonosov.blogspot.com

13 pointsavodonosov11 comments

I was under the impression that you can set up an S3 bucket so that it behaves like this with no additional server.

I need access permissions so that public can upload new files, but after file is uploaded it can't be modified.

Amazon permission system does not allow such a configuration.

It looks like enabling Versioning on the S3 bucket might be enough. When you want to generate a file's public-facing URL, GET its metadata and then append the oldest version from the returned list.

This may help: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGET...

Thanks, but it won't work. The file URLs are published in reports and the file URL must be constant. With versioning the constant URL is the latest (i.e. possibly overwritten) version of the file.

I have studied versioning and other aspects of Amazon API, trying to find a way or trick to enforce my rules, but there is no such way.

Why can't you publish the URL with the version appended? The full (location + version) URL translates to a static resource. Unless you imagine people don't enjoy seeing query-strings in their reports, perhaps.

Or is it that you have to be able to predict the full URL in advance of the upload? In that case, yes, adding a server giving out signed URLs to the bucket is probably the best solution.

Alternatively, if you really want to be sure the content can't change, you can generate a .torrent file from the document, hash it, stick it up on a tracker somewhere, and then give out magnet:?xt=urn:sha1:[...] URNs. Those can't mean anything other than the document they referred to when published, even if you as the server-authority wanted them to!

...

Or, you could try to use DURIs[1] and hope that browsers will advance enough to automatically translate them to Mementos from a TimeGate[2] delivered by your unversioned resource. Sadly, some "standards", aren't. ;)

[1] http://tools.ietf.org/html/draft-masinter-dated-uri-05

[2] http://www.mementoweb.org/guide/quick-intro/

You are right, it might work. Why did I rule out versioning? Maybe just was overloaded by alternatives. Thanks, I will consider this alternative if I will need to change the solution next time.

> Unless you imagine people don't enjoy seeing query-strings in their reports, perhaps.

I am concerned about this a little, although I probably can live with that if everything else works OK.

About the pretty URLs. I can even try to submit all the logs to the same object /my-bucket/log. The version ID is then the key to distinguish them.

http://my-bucket.s3.amazonaws.com/log?versionId=L4kqtJlcpXro...

http://my-bucket.s3.amazonaws.com/log?versionId=X4xxxJlcpXro...

http://my-bucket.s3.amazonaws.com/log?versionId=Y4yyyJlcpXro...

Sure it does. You can create an IAM user, give that user only PutObject permissions to your bucket, and publicly share the key/secret key for that IAM user. Then people can use those creds with any s3 upload utility.

Alternatively you could probably make a static web form that does that automatically thus isolating people from the need to understand S3 utilities. You could even make it drag/drop enabled so that literally all one has to do to upload a file is drag it to a web page.

The OP is talking about preventing someone from overwriting their own files, mind.

Firebase can do this for you. It has a very flexible expression-based permissions model. You can set your rule to:

".write":"!data.exists()"

And people will be able to write only new items.

Firebase is an interesting thing, but it's for dynamic structured data and costs $49 / mo. Too much for just publishing plain static files.

Reply on news.ycombinator.com