Авторизация Url с помощью MVC и ASP.NET идентичность

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

первоначально казалось, что UrlAuthorizationModule был бы ответ. Я следил за этой статьей,понимание авторизации URL IIS 7.0, и я могу сделать модуль для работы в том смысле, что он реагирует на элементы конфигурации в web.config.

моя текущая проблема в том, что я думаю он принимает правила на основе анонимного пользователя в IIS, а не аутентифицированного пользователя в asp.net личность.

Тестовой Среде

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

  • на Visual Studio 2015.
    • новое значение по умолчанию .net 4.6.2 веб-проекта
    • шаблон MVC
    • проверка подлинности = Individual User Accounts
  • IIS 8 (для тестирования вне Visual Studio)
    • аутентификация - > анонимная аутентификация (включена)

добавить web.config

<configuration>
...
<location path="Data">
  <system.webServer>
    <security>
      <authorization>
        <clear/>
        <add accessType="Deny" users="*"/>
        <add accessType="Allow" users="?"/>
      </authorization>
    </security>
  </system.webServer>
</location>
...
</configuration>

добавить в структуру папок

/Data/Protected.html // this file just has some basic Hello World content to display so you can see if it is loaded or not.

наблюдается Результаты

  • С этой конфигурацией все в Data путь всегда запрещен, не имеет значения, аутентифицирован пользователь или нет.
  • то же самое верно, если я переключаю 2 строки для Deny и Allow на web.config.
  • если я полностью удалю строку с Deny тогда доступ всегда разрешен, даже если пользователь не прошел проверку подлинности.
  • если я добавлю роль и использую roles С именем роли, а не users атрибут роль также полностью игнорируется.

Теперь Что?

что я упустил? Как я могу получить Url Authorization модуль для работы с MVC / WebAPI и ASP.NET личность Individual user accounts или это просто не выполнимо?

я также открыт для альтернативных идей, возможно, ответ заключается в написании пользовательского HttpModule или HttpHandler?


побочные Примечания

почему & Особенности

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

1 ответов


[TL; DR;]
Перейти к " полная корневая сеть.config" раздел, чтобы увидеть необходимую сеть.настройка конфигурации.

проверьте это в режиме инкогнито, чтобы предотвратить проблемы кэширования браузера! И использовать Ctrl+F5 потому что скрипты и html-файлы кэшируются.

сначала запретить доступ ко всем анонимным пользователям в интернет.конфиг.

<authorization>
    <deny users="?"/>        
</authorization>

веб.config здесь позволяет одной папке быть публично работает. Эта папка, в моем примере здесь, называется css и сидит в корне приложения MVC. Для папки css я добавляю следующую авторизацию в корневой веб-сайт.config:

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

вы можете добавить больше этих путей расположения, если хотите больше общих папок.

пока все другие файлы не будут доступны, пока пользователь не войдет в систему, папка css и ее содержимое всегда будут доступны.

я также добавил статический обработчик файлов в корневой сети.config,это критично, поскольку вы хотите, чтобы запрос управлялся asp.net конвейер для определенного типа файлов:

<handlers>
    <add name="HtmlScriptHandler" path="*.html" verb="*" preCondition="integratedMode" type="System.Web.StaticFileHandler" />
</handlers> 

полный интернет.config

<system.web>
    <authentication mode="None" />
    <authorization>
        <deny users="?"/>        
    </authorization>
    <compilation debug="true" targetFramework="4.6.2" />
    <httpRuntime targetFramework="4.6.2" />
</system.web>
<location path="css">
    <system.web>
        <authorization>          
            <allow users="*"/>
        </authorization>
    </system.web>
</location>
<system.webServer>
    <modules>
        <remove name="FormsAuthentication" />           
        <remove  name="UrlAuthorization" />
        <add  name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule"  />     
    </modules>
    <handlers>
        <add name="HtmlScriptHandler" path="*.html" verb="*" preCondition="integratedMode" type="System.Web.StaticFileHandler" />
    </handlers>      
</system.webServer>

ASP.NET по умолчанию правила allow и deny применяются только к файлам, обрабатываемым управляемым обработчиком. Управляемый обработчик не управляет статическими файлами.

вы также можете установить: (не делай это, если не очень нужно!)

 <modules runAllManagedModulesForAllRequests="true">

С runAllManagedModulesForAllRequests="true" все HTTP-модули будут выполняться по каждому запросу, а не только управляемым запросам (например .aspx, ashx). Это означает, что модули будут работать на каждом .формат JPG., файл GIF., стиль CSS., формат HTML. ,документ PDF. ,.. запрос.


одна важная вещь
Вам не нужно добавлять UrlAuthorizationModule в раздел Модули, поскольку он уже является частью ASP.NET трубопровод. Это означает, что он будет работать только для управляемых файлы, а не статические!

если теперь удалить, а затем повторно добавить UrlAuthorizationModule в раздел модулей, он будет работать под предварительным условием "integratedMode", а не под" managedHandler " больше! И поэтому будет иметь доступ к статическим файлам.

<remove  name="UrlAuthorization" />
<add  name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />


Если задано предварительное условие managed: <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" preCondition="managedHandler" />, то UrlAuthorizationModule больше не будет ограничивать доступ к статическим файлам.

вы можете проверить это, обратившись к файлу сценария в папка scripts успешно при выходе из системы. Нажмите Ctrl+F5, чтобы получить новую копию файла сценария.


разница между ASP.NET UrlAuthorization IIS url Authorization

важно иметь в виду, что предварительное условие managedHandler находится на ASP.NET модуль UrlAuthorization. Условие говорит вам что модуль авторизации URL вызывается только тогда, когда код что обрабатывает запрос сопоставляется с управляемым кодом, обычно .aspx или .asmx-страницы. С другой стороны, авторизация IIS URL применяется ко всем содержание. Предварительное условие managedHandler можно удалить из ASP.NET модуль авторизации Url. Это там, чтобы предотвратить производительность штраф вы должны заплатить, когда каждый запрос (например, запрос на .html или .jpg pages) придется пройти через управляемый код.

П. С.: Некоторые веб.атрибуты настройки случае чувствительный!