ASP / ASP.NET最好的办法来处理写权限？

首先让我开始说，我是一个相当大的信徒，几乎总是有一个比磁盘写东西更好的解决scheme。 无论是将数据写入数据库，还是提供Web服务，写入磁盘都应该是最后的select。
这就是说有一些有效的原因，但这是有点棘手，并依赖于为什么应用程序需要写出文件。

将数据写在代码运行的地方是绝对需要的。 允许最终用户写入ASPX / ASP引擎可以解释/执行代码的path是不好的，原因很明显。

其他一些影响这个事情的是：

1. 无论您是在域帐户或标准networking服务下运行工作进程。 认识到当您授予IIS_WPG组对写入文件夹的写入访问权限时，服务器上默认帐户下运行的任何ASP.NET应用程序都可以将文件写入该文件夹，这一点很重要。 在多个应用程序运行的服务器上，这是不太理想的configuration，特别是当应用程序不受信任和/或在ISP /共享主机环境中运行时。
2. 生成的文件是否需要networking可用。 如果您的应用程序只是写出一些非网页可查看的文件，只需创build目录，授予权限，并将应用程序configuration为读取/写入正确的位置即可。 如果应用程序需要写出可浏览的网页文件（这在内容pipe理场景中相当常见），则需要创build映射到可写目录的虚拟目录（无需执行代码/脚本权限）。
3. 无论您是否在负载均衡/ Web场环境中工作。 如果您的应用程序在一个养殖环境中运行，并且出于某种原因需要将文件写入磁盘，则会出现一个全新的问题。 如何让webserver1上的用户生成的文件与webserver2上生成的文件保持同步？ 通过一些令人费解的syncronization脚本来做到这一点是痛苦的，充满了种族/同步问题。 实现这一点的最好方法是在第三台服务器上创build共享（理想情况下是具有一定冗余度的群集）并将数据存储在那里。 如果您正在域帐户（安全最佳实践）下运行您的工作进程，甚至可以映射到应用程序中的共享，而无需用户/代码或web.config中的任何地方（使审计/安全人员感到满意）。 IIS还能够将虚拟目录映射到UNCpath，因此这不会影响您使此内容网站可见的能力。

大概押注在stackoverflow.com上查看…

最佳做法是将该文件夹放在文档根目录的外部，并从文件系统读取您的应用程序。 否则，将该文件夹设置为除ASP [.NET]用户以外的只读文件夹，并使用应用程序的内部授权控制写入特权。

App_Data文件夹

为了提高ASP.NET应用程序使用的数据的安全性，已经为ASP.NET应用程序添加了名为App_Data的新子文件夹。 存储在App_Data文件夹中的文件不会响应直接的HTTP请求而返回，这使App_Data文件夹成为存储在您的应用程序中的数据的推荐位置，其中包括.mdf（SQL Server Express Edition），.mdb（Microsoft Access）或XML文件。 请注意，使用App_Data文件夹存储应用程序数据时，应用程序的身份对App_Data文件夹具有读写权限。

ASP.NET数据访问中的新增function

默认情况下，App_Data是可写但不可读的。 服务器似乎抵制任何改变这一点的企图。 因此，最好创build一个全新的文件夹，并将其上的权限更改为不可执行，可读写和可写。