ASP / ASP.NET Лучший способ обрабатывать разрешения на запись?

Прежде всего позвольте мне начать с того, что я довольно сильно верю, что почти всегда есть лучшее решение, чем запись на диск. Будь то запись данных в базу данных или загрузка веб-служб, запись на диск должна быть последним вариантом.
При этом есть несколько веских причин, но это довольно сложно и зависит от того, почему приложение должно записывать файлы.

Наличие данных, написанных за пределами того места, откуда выполняется код, является абсолютным требованием. Разрешение конечным пользователям писать по пути, по которому движки ASPX / asp могут интерпретировать / выполнять код, является плохим по очевидным причинам.

На это влияют и другие факторы:

1. Независимо от того, запускаете ли вы рабочий процесс под учетной записью домена или стандартной сетевой службой. Важно понимать, что когда вы предоставляете группе IIS_WPG доступ на запись в папку, любое приложение ASP.NET, работающее под учетной записью по умолчанию на сервере, может записывать файлы в эту папку. Это далеко не идеальная конфигурация на серверах, на которых работают несколько приложений, особенно когда приложения не являются доверенными и / или работают в среде ISP / общего хостинга.
2. Должны ли сгенерированные файлы быть доступны в сети или нет. Если ваше приложение просто записывает некоторые файлы, не доступные для просмотра в Интернете, вам нужно просто создать каталог, предоставить права и настроить приложение для чтения / записи в нужное место. Если приложению необходимо записывать файлы, доступные для просмотра в Интернете (это довольно часто встречается в сценариях управления контентом), вам необходимо создать виртуальный каталог (без прав на выполнение кода / сценариев), который сопоставляется с вашим каталогом, доступным для записи.
3. Независимо от того, работаете ли вы в среде с балансировкой нагрузки / веб-фермы. Если ваше приложение работает в фермерской среде и по какой-то причине ему необходимо записывать файлы на диск, вы столкнетесь с совершенно новой проблемой. Как вы синхронизируете сгенерированные пользователем файлы на webserver1 с файлами, созданными на webserver2? Выполнение этого с помощью запутанного скрипта синхронизации в лучшем случае болезненно и связано с проблемами расы / синхронизации. Лучший способ реализовать это - создать общий ресурс на третьем сервере (в идеале - кластер с некоторой избыточностью) и хранить там данные. Если вы запускаете свои рабочие процессы под учетными записями домена (Лучшая практика безопасности), вы даже можете сопоставить общий ресурс в приложении, не имея пользователя / прохода где-либо в коде или web.config (что делает людей, выполняющих аудит / безопасность, счастливыми). IIS также может сопоставлять виртуальные каталоги с путями UNC, поэтому это не повлияет на вашу способность сделать этот контент доступным для просмотра в Интернете.

Папка 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

App_Data по умолчанию доступен для записи, но не для чтения. Сервер, кажется, сопротивляется любой попытке изменить это. Таким образом, лучше создать совершенно новую папку и изменить права доступа к ней на НЕ ВЫПОЛНЯЕМЫЕ, ЧТЕНИЕ и ЗАПИСЬ.

Наверное, держу пари, чтобы посмотреть на stackoverflow.com...

Лучше всего поместить эту папку ВНЕ корня вашего документа и позволить вашему приложению читать из файловой системы. В противном случае сделайте папку доступной только для чтения, за исключением пользователей ASP [.NET], и управляйте правами записи с помощью внутренних разрешений вашего приложения.