The question can be seen as both practical and theoretical.
I am designing a system involving a HTTP client (Flash Player application) and an HTTP server “backend”. There are registered users each with their own private image library. Images can be uploaded and of course subsequently retrieved.
Since users authenticate with cookies carrying session identifiers, it suddenly became clear to me (and hence the question) that I can provide the following kind of URL for an authenticated client to retrieve an image (‘asset’ in my terminology). Note that asset identifiers are unique even across users, i.e. no two users will both have an asset with ID of say, 555. Also, an asset identifier is assumed to be REALLY persistent, i.e. the ID is non-reusable. The URL I was thinking of is:
http://myserver/user/asset/<asset_id>
Brackets denote variable value, i.e. obviously these and the ‘asset_id’ are not to be taken verbatim here, they denote the actual asset identifier. The HTTP request “to” the above URL is expected to carry a cookie header with the user session identifier, which uniquely authenticates and authorizes the user as the owner of the asset requested.
I am very much after permanent URLs (“Cool URIs don’t change” as Tim Berners-Lie said once), but obviously, since the asset resources are private to the user that uploads/owns them, they are not to be cached by any intermediate proxies, only user agents.
Can we consider the URL above as a good way to identify a user asset? My worry is that the response will vary depending on whether a valid session identifier cookie header is supplied or not, and so there is not a one-to-one relationship between the URL and the response. But there is not much one can do, is it? Server HAS to check that the user is authorized to retrieve the asset, right? If you guys have any better suggestions for a solution here, I am also anxious to hear it. Thanks.
you’ve said it all, I wouldn’t change a thing about your strategy 🙂 If an unauthorized user tries to access some asset, simply give him a 403 http code … that’s the correct and expected response in that case