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.
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. ;)
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.
This may help: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGET...