使用 ASP.NET 的临时文件下载链接 [英] Temporary file download link with ASP.NET

问题描述

我想知道如何在有限的时间内为我的文件生成一个临时下载地址.我知道这不是最佳实践，根据 http://www.devx.com/codemag/Article/34535/1954
但我很想知道如何使用 urlrewriting 使用 GUID 或其他一些神秘的命名技术生成文件名，并使其在有限的时间内可用.
如果有人给我推荐一篇关于它的好文章，我将不胜感激.

解决方案

首先你需要某种形式的标识符.您建议一个 GUID，这很容易做到，Guid.NewGuid().ToString("n") 为您提供了这样的标识符.

您谈到了 URI 重写，但这实际上只是一点修饰.您当然可以进行一些重写以将 /myFiles/a948ec43e5b743548fd9a77c462b953e 转换为 /myFiles/download.aspx?id=a948ec43e5b743548fd9a77c462b953e 或查看代码后查看表>myFiles/download.aspx?id=3 或 myFiles/download.aspx?fileName=myNewDownload.pdf.这与任何其他 URI 重写任务相同，所以现在让我们忽略它并假设我们有一个请求进入 /myFiles/download.aspx?id=a948ec43e5b743548fd9a77c462b953e 是否是由于重写与否.

好的.您有一个标识符，您需要将其与三件事相匹配:流、内容类型和到期日期.

您可以将所有这些存储在文件系统中，将所有这些存储在数据库中，或者将详细信息存储在数据库中，包括将流存储为文件系统中的文件的路径.

假设将其存储在文件系统中，名称如下:

a948ec43e5b743548fd9a77c462b953e.application_pdf 和 a5d360178ec14e97abd556ed4b7709cf.text_plain;charset=utf-8

请注意，我们没有使用普通的 Windows 文件扩展名，因此我们可以很好地处理上传机器与您的服务器具有不同绑定的情况.

在 a948ec43e5b743548fd9a77c462b953e 是需要的项目的情况下，我们首先查看创建日期，如果它太早了(文件已过期)，我们会发送一个 410 GONE 标头，其中包含一条错误消息，说明文件已过期(我们可以同时删除该文件以清理使用情况 - 或者可能会截断它，以便它保留该文件曾经存在的记录，但存储量为 0 字节).

否则我们将Response.ContentType 设置为application/pdf"，然后将Response.TransmitFile 设置为发送文件.

如果我们以不同于文件的方式存储流，我们希望以小块的形式发送它(4096 很好地匹配系统其他部分的其他缓冲区)，并且在它非常大的情况下定期调用 Response.Flush() 以防止内存问题.

你的基本系统就完成了.好处包括存储原始文件名并将其发送到内容处置标头中，并遵守 Range 请求，以便用户可以恢复失败的下载，而不必从头开始.

所有这些都与用于确保只有正确的人拥有文件的任何身份验证非常正交 - 您可以将其与任何类型的登录系统一起使用，或者您可以将其公开但有时间限制.

I'd like to know how I can generate a temporary download address for my file for a limited time. I know that's not the best practice and probably using HttpHandlers is the way to go according to http://www.devx.com/codemag/Article/34535/1954
But I'm curious to know how I can use urlrewriting to generate a file name using a GUID or some other cryptic naming technique and make it available for a limited time.
I'd appreciate if anyone points me a good article about it.

解决方案

Well first you need some form of identifier. You suggest a GUID and that's easily done, Guid.NewGuid().ToString("n") gives you such an identifier.

You talk of URI rewriting, but that's really just a bit of polish. You could certainly do some rewriting to turn /myFiles/a948ec43e5b743548fd9a77c462b953e into /myFiles/download.aspx?id=a948ec43e5b743548fd9a77c462b953e or even (after checking a look up table) into myFiles/download.aspx?id=3 or myFiles/download.aspx?fileName=myNewDownload.pdf. This is the same as any other URI rewriting task, so for now lets just ignore it and assume we've a request coming into /myFiles/download.aspx?id=a948ec43e5b743548fd9a77c462b953e whether that is due to rewriting or not.

Okay. You've got an identifier, you need to match this to three things: a stream, a content type and an expiry date.

You could store all of this in the file system, all of it in a database or the details in the database including a path to where the stream is stored as a file in the filesystem.

Lets say store it in the file system with names like:

a948ec43e5b743548fd9a77c462b953e.application_pdf and a5d360178ec14e97abd556ed4b7709cf.text_plain;charset=utf-8

Note that we aren't using normal windows file extensions, so we deal well with the case where the uploading machine had different bindings to your server.

In the case of a948ec43e5b743548fd9a77c462b953e being the item required we first look at the creation date and if it's too long ago (the file has expired), we send a 410 GONE header with an error message explaining the file has expired (we can also delete the file at this point to clean up usage - or perhaps truncate it so it remains a record that the file used to exist, but is 0bytes of storage).

Otherwise we set Response.ContentType to "application/pdf" and then Response.TransmitFile to send the file.

If we'd stored the stream a different way than as a file, we'd want to send it in small chunks (4096 nicely matches other buffers in other parts of the system) and in the case of it being very large call Response.Flush() periodically to prevent memory issues.

That's your basic system done. Niceties would include storing the original file name and sending it in a content-disposition header, and obeying Range requests so that a user can resume a failed download rather than have to start from the beginning.

All of this is pretty orthogonal to any authentication used to ensure only the correct person has the file - you could use it in tandem with a login system of whatever sort, or you could leave it public but time-limited.

这篇关于使用 ASP.NET 的临时文件下载链接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！