My IIS ASP.NET-based website allows users to download a file. I’m trying to figure out a good way to stamp an ID into the file before/as the user downloads it so each user could potentially have a uniquely stamped file.
Finding the offset and writing the bytes to the file isn’t the hard part. What I’m trying to figure out is what to trigger on so my write procedure could be called, and some way to manage multiple users downloading the same file (I’m assuming writing the file to a unique temp folder, stamp it, then download).
Suggestions?
Bonus: Some of these files will be executable files which were code signed. Stamping will invalidate the digital signature, so I’ll need to sign them again after stamping. Thoughts on how best to do that? (I assume fetching a timestamp during the signing process will take too long, so will have to sign without the timestamp).
Just treat it as any resource request: Only, instead of sending back HTML, you send back the appropriate data through the response stream (and the appropriate headers, hopefully).
See this little post on how to send back an image. Now, if the stamping isn’t terribly invasive, just read the file and write the “stamped” version out in a streaming process.
Of course, I have made some assumptions about resources, but…
If you do need/want to pass off to temporary files (and let the web-server do static file serving, or whatnot), then just use the resource request to generate the file and respond with a redirect to the appropriate (now generated) static resource. If the resource is generated with a nonce, and they are not otherwise list-able, then it might be enough to rely on “security through obscurity” and have the link remain valid until it is purged (say all files over 6 hours are purged on occasion). It might be sufficient to make the nonce generated on a hash of the file (to eliminate the need to map ID->File in a database, e.g.)… but again, it might not be.
Happy coding.