Protect link for public downloads

Question

I've got SL application where i should implement file managment subsystem. I've got hierarchical structure of files\folders(just description). Also each file\folder has its own permissions to users\groups. I would like implement that one user who has permission to download file couldn't give it to another user, who hasn't this permission. So if user has download permission he get link www.site.com/file.rar and download it. But he could give this link to another person without permission. What alogorithm is more appropriate in this case? Any help would be appreciated.

Answer 1

You could store permission information in a database. Then each user will have their own account and permission set. Then you can set user group permissions to file groups or individual files.

This could probably also be achieved using the file permission information stored at the operating system level.

You can then have a dynamic page which takes a filename as a request and verifies a user name and password combination and checks whether that file is allowed for that person.

So when someone goes to that file link, they first have to provide the correct credentials to download, otherwise they are denied access.

I hope this helps, it wasn't a directly SilverLight answer but more language agnostic

Answer 2

The web server needs to be in charge and provide authentication and authorization for any file requests. It's not specific to Silverlight as this is a general problem.

Your web server must validate each file download request against the currently logged in user (which, if you were using ASP.NET, could be using one of the authentication methods such as Forms Auth, or Windows Auth for example). You might have an HTTP Handler for example that does this validation and allows the download (and provides the download file's bytes). Here's an older example, but looks like it's still applicable for ASP.NET for example.

Or, you could provide a securely generated, expiring (maybe one time use?), token in place of a file name, which maps to a preauthorized file request, and again serves up the file on demand. This one is more difficult to manage in many respects and could lead to a less pleasant user experience if not done carefully (especially if the download may be interrupted and needs to be restarted, then the old token may not be valid, etc.).

I'd go with the first suggestion as it's more reliable and easier to control and manage (ignoring technology specifics as that pattern is available in all web platforms).