Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm looking for a way to distribute sample files to clients. Requirement is that it's (relatively) simple to upload files, a link can be sent to a client who can download the file with a browser, the client's link can't be used to find other files

At the moment I do this with Dropbox and scripts that create a unique dropbox folder and generate a link like" rather than manage passwords

There is no need to encrypt the content, files are typically <1Gb and we only expect a few downloads a day. We don't want to host it on our website (don't ask) and we want a service that's going to be around for awhile but the data is stored locally so 9-9s redundancy isn't an issue

share|improve this question – Basil Nov 2 '11 at 20:36
Well obviously we would have redundancy - we would copy it to another cloud service ;-) – Martin Beckett Nov 2 '11 at 20:37
My DR strategy is "I don't know anyone like that" :) – Basil Nov 2 '11 at 20:38
up vote 2 down vote accepted

I'll provide an S3 answer, since it is one of your tags. Amazon's S3 allows you to set permissions on files, and create a signed URL with an expiry time. Using these two ideas together, it is possible to create a system that functions as a one time use URL. Additionally, S3 has two levels of storage, so if redundancy isn't a major factor for you, it is possible to save a bit by using the reduced redundancy storage. As with all AWS services though, you will have to pay for bandwidth used. S3 also charges a fee per request to your files.

Unlike the typical S3 implementation, where the file permissions are set to public, here you will be setting the permissions to private, and signing with your access key to grant access.

If you do not care whether your clients share the link with others or download multiple times (so long as they cannot access any other files) then the implementation is quite simple, you will just need to create a (reasonably far) future expire date with the signed URL. So, for instance, you upload your file to S3 (it is private by default); create a signed URL with a one week expiry; and your client, within the next week, can access the file using the URL provided, as many times as they wish. They cannot access any other files, since they do not have signed URLs - and all the files are private.

The problem with the above scenario is one of time - you don't want to keep a URL available for too long, yet you need to give enough time for your client to access the file - it also takes some effort to validate that your client has in fact viewed the file (i.e. you would turn on logging on S3, and check your logs).

The alternate scenario requires a partial implementation on your site, instead of being fully reliant on S3. Create a page that accepts an unique ID (stored in a database) and send your client a link to your page including that ID. When your client accesses the page, you generate a signed S3 URL that expires in the near future (30s). (At the same time, you can of course, log that the ID is no longer valid and that your client has accessed the file). Launch the download using the generated URL. In this way, clients can only use the URL once - they cannot make it available to others (although, they could always make the file itself available to someone else), they can use the link you email them at any time (since there is no expiry on that), and since you are using signed URLs, they cannot access any other files (even if they guess the paths/filenames).

share|improve this answer
I just had a play with s3, the new web console makes it a lot easier than the old s3cmd. I just create a long pseudo-random bucket name and a meaningful file name to pass to the client. I don't think this was easy/possible(?) when I first played with s3. – Martin Beckett Nov 2 '11 at 21:22
ps. Am I correct that the bucket isn't browsable even if you know the bucket name? Can you overide this? I set the bucket to public but still get an xml error – Martin Beckett Nov 2 '11 at 21:23
S3 doesn't reveal the directory contents (i.e. no index - although, you can set an index file to be served when someone accesses the document root) – cyberx86 Nov 2 '11 at 21:27

For something more suited to non technical users I use

It's free for files up to 50MB and very easy for anyone to use.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.