Подтвердить что ты не робот

Как защитить статические файлы с помощью аутентификации формы ASP.NET в IIS 7.5?

У меня есть сайт, работающий на сервере IIS 7.5 с ASP.NET 4.0 на общем хосте, но в полном доверии.

Сайт является базовым "файловым браузером", который позволяет посетителям войти в систему и получить список файлов, доступных для них, и, очевидно, загрузить файлы. Статические файлы (в основном файлы PDF) находятся в подпапке на сайте, называемом данными, например. http://example.com/data/...

Сайт использует аутентификацию формы ASP.NET.

Мой вопрос: как заставить механизм ASP.NET обрабатывать запросы на статические файлы в папке с данными, так что запрос на файлы аутентифицируется ASP.NET, и пользователи не могут глубоко ссылаться на файлы и файлы захвата, которые им не разрешены?

С наилучшими пожеланиями, Эгил.

4b9b3361

Ответ 1

Если пул приложений запущен в интегрированном режиме, вы можете сделать следующее.

Добавьте на свой веб-сайт верхнего уровня web.config.

  <system.webServer>
    <modules>
      <add  name="FormsAuthenticationModule"  type="System.Web.Security.FormsAuthenticationModule" />
      <remove  name="UrlAuthorization" />
      <add  name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule"  />
      <remove  name="DefaultAuthentication" />
      <add  name="DefaultAuthentication"  type="System.Web.Security.DefaultAuthenticationModule" />
    </modules>
  </system.webServer>

Теперь вы можете использовать стандартные разрешения ASP.NET в своем web.config для принудительной проверки подлинности всех файлов в каталоге.

<system.web>
    <authorization>
        <deny users="?" />
    </authorization>
    <authentication mode="Forms" />
</system.web>

Ответ 2

У меня была та же проблема с получением роли для аутентификации. Сквозь проб и ошибок я, наконец, получил его для работы с небольшим редактированием кода @Joel Cunningham:

<modules runAllManagedModulesForAllRequests="true" >

Я использовал эти два сайта в качестве ссылок: http://forums.iis.net/t/1177964.aspx и http://learn.iis.net/page.aspx/244/how-to-take-advantage-of-the-iis-integrated-pipeline/

Ответ 3

Это старый поток, но я оказался на нем и столкнулся с той же проблемой, что и у Egil. Вот версия Joel fix, которая включает в себя роли:

<modules runAllManagedModulesForAllRequests="false">
      <remove name="FormsAuthenticationModule" />
      <add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
      <remove name="UrlAuthorization" />
      <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule"  />
      <remove name="RoleManager" />
      <add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
      <remove name="DefaultAuthentication" />
      <add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>

Ответ 4

Приложение:

Как заметил @eych, принятый ответ также блокирует доступ к папке ~/Content (или где у вас есть CSS), ~/Scripts и так далее.

Если вы хотите разрешить исключения - то есть разрешить доступ к определенным файлам/папкам неаутентифицированным пользователям - вы можете сделать это с помощью элемента location. Добавьте следующее в web.config:

  <location path="Content">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>

Обновление: альтернативное решение состоит в том, чтобы оставить доступ по умолчанию - что позволит получить доступ к вашему CSS/JavaScript/и т.д. - и применить "блокировку" (только) к папке, где хранится статический контент:

<location path="data">
  <system.web>
    <authorization>
      <deny users="?"/>
    </authorization>
  </system.web>
</location>

Предупреждение: в нашем случае (сайт MVC) нам нужно было декорировать все действия нашего контроллера (кроме входа в систему) с помощью [AuthorizeAttribute]. В любом случае, это хорошая идея, но ранее в этом не было необходимости (поскольку ранее любой неавторизованный запрос перенаправлялся на страницу входа).

Ответ 5

Я хотел знать, почему потребуется повторное добавление модулей (с настройками по умолчанию), которые по умолчанию добавляются для Integrated Pipeline, поэтому я немного углубился.

Вам нужно удалить и повторно добавить модули, потому что по умолчанию модули не добавляются по умолчанию. У них есть предварительное условие для обратной совместимости для запуска только для контента, обработанного зарегистрированным обработчиком ASP.NET(например,.aspx-страницами).

Значение по умолчанию выглядит следующим образом:

<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" 
         preCondition="managedHandler" />

Удаляя модули и повторно добавляя их без предварительного условия, эти отдельные модули запускаются для каждого запроса (включая статический контент). Он более гранулирован, чем включение runAllManagedModulesForAllRequests.

Вы можете прочитать об этом в нескольких статьях, когда Интегрированный трубопровод был представлен с IIS 7:

Обратите внимание, что во второй статье есть имя опечатки или имя модуля (и ответ @John) в какой-то момент был изменен с FormsAuthenticationModule на FormsAuthentication.

Набор рабочих модулей в IIS 7.5 до 8.5 выглядит так для меня:

<system.webServer>
  <modules>
    <!-- Re-add auth modules (in their original order) to run for all static and dynamic requests -->
    <remove name="FormsAuthentication" />
    <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
    <remove name="DefaultAuthentication" />
    <add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
    <remove name="RoleManager" />
    <add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
    <remove name="UrlAuthorization" />
    <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
  </modules>
</system.webServer>

Ответ 6

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

Сначала добавьте поставщика веб-страниц в Web.config:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.web> 
    <compilation>
      <buildProviders>
        <add type="System.Web.Compilation.PageBuildProvider" extension=".html"/>
      </buildProviders>
    </compilation>
  </system.web> 
</configuration>

Затем добавьте обработчик страницы factory:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.web> 
    <httpHandlers>
      <add type="System.Web.UI.PageHandlerFactory" path="*.html" verb="*"/>
    </httpHandlers>
  </system.web> 
</configuration>

Затем добавьте обработчик страницы:

<?xml version="1.0" encoding="UTF-8"?>
<configuration> 
  <system.webServer>
    <handlers>
      <add scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness32" path="*.html" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" name="HtmlHandler-Classic-32" />
      <add scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness64" path="*.html" verb="GET,HEAD,POST,DEBUG" name="HtmlHandler-Classic-64"/>
    </handlers>
  </system.webServer>
</configuration>

Это сработало для меня. (Кредит: http://www.ifinity.com.au/Blog/EntryId/66/How-To-301-Redirect-htm-or-html-pages-to-DotNetNuke-aspx-pages.)