Как работает авторизация местоположения, когда у пользователя несколько ролей?

#asp.net #web-config #forms-authentication

#asp.net #web-config #формы-аутентификация

Вопрос:

В моем web.config есть это правило авторизации:

   <location path="Views/Administrator">
    <system.web>
      <authorization>
        <allow roles="roleA, roleB" />
        <deny users="*" />
      </authorization>
    </system.web>
  </location>
  

Что это значит?

Когда я тестирую процесс входа, пользователь в RoleA или пользователь в RoleB может получить доступ ко всему контенту в разделе Просмотры / Администратор, НО когда пользователь входит в систему с помощью roleC, им отказывают в доступе. Пока это имеет смысл. На первый взгляд, это подразумевает, что пользователь с RoleA или RoleB разрешен. НО когда я назначаю роли RoleA и roleC одному и тому же пользователю и пытаюсь войти в систему, мне отказывают. Это подразумевает, что правило авторизации просматривает все роли, в которых находится пользователь, и отказывает пользователю в доступе, если у пользователя нет всех ролей, определенных в <allow /> теге.

Итак: «Как работает авторизация местоположения, когда у пользователя несколько ролей?»

Ответ №1:

Хорошо, итак, я только что создал новое веб-приложение, которое использует материал менеджера ролей по умолчанию. Я создал три роли: RoleA, RoleB, roleC. и в моем приложении я добавил ту же самую запись конфигурации, которую вы используете выше, но изменил путь к странице по умолчанию «About.aspx».

После тестирования различных конфигураций ролей роли, похоже, работают именно так, как можно было бы ожидать. Если пользователь является участником нескольких ролей, например RoleA и roleC, если ваша конфигурация настроена так, как указано выше, разрешите «RoleA, RoleB», мой пользователь получает доступ независимо от порядка. Уберите RoleA в конфигурации, и у моего пользователя больше не будет доступа. Уберите RoleB и readd RoleA, у моего пользователя снова есть доступ, перечитайте их обоих, у пользователя есть доступ.

Редактировать 2 — Удаление изображения с помощью «RoleGroup», поскольку я полагаю, что это добавляет путаницы.

http://www.asp.net/security/tutorials/role-based-authorization-cs.
Содержит довольно хорошее объяснение того, как работает авторизация на основе ролей. Нет хорошей информации о нескольких ролях, хотя.

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

https://web.archive.org/web/20181010194753/http://www.4guysfromrolla.com:80/articles/082703-1.2.aspx

Редактировать — Добавление информации о моем тесте.

Для дальнейшего объяснения того, как я тестирую:

Я создал обычного пользователя и 3 роли в средстве веб-администрирования. Создано 3 роли. И назначил RoleA и roleC моему пользователю.

Веб-администратор

Оттуда вот мой конфигурационный файл. Какая веб-конфигурация по умолчанию используется в новом проекте с вашими настройками, добавленными выше.

 <?xml version="1.0"?>
<configuration>
  <connectionStrings>
    <add name="ApplicationServices" connectionString="data source=.SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true"
     providerName="System.Data.SqlClient" />
</connectionStrings>
<system.web>
    <compilation debug="true" targetFramework="4.0" />

 <authentication mode="Forms">
   <forms loginUrl="~/Account/Login.aspx" timeout="2880" />
 </authentication>

<membership>
  <providers>
    <clear/>
    <add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="ApplicationServices"
         enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="false"
         maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10"
         applicationName="/" />
  </providers>
</membership>

<profile>
  <providers>
    <clear/>
    <add name="AspNetSqlProfileProvider" type="System.Web.Profile.SqlProfileProvider" connectionStringName="ApplicationServices" applicationName="/"/>
  </providers>
</profile>

<roleManager enabled="true">
  <providers>
    <clear />
    <add connectionStringName="ApplicationServices" applicationName="/"
      name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider" />
    <add applicationName="/" name="AspNetWindowsTokenRoleProvider"
      type="System.Web.Security.WindowsTokenRoleProvider" />
  </providers>
</roleManager>

</system.web>

<system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>


 <location path="About.aspx">
    <system.web>
        <authorization>
            <allow roles="roleA, roleB" />
            <deny users="*" />
        </authorization>
    </system.web>
 </location>
  

Комментарии:

1. Спасибо за ваш ответ. Я не использую ролевые группы. Ролевые группы, похоже, связаны с asp.net управление. Проблема, с которой я сталкиваюсь, заключается в том, что мой пользователь перенаправляется обратно на страницу входа, как только я назначаю дополнительную роль, которой нет в списке разрешенных ролей, разделенных запятыми.

2. @subt13 — «Ролевые группы» — это только то, что в статье называется ролями. Они не связаны с asp.net управление.

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

4. @subt13 — исправьте, мое приложение webforms по умолчанию, казалось, обрабатывало несколько ролей, как если бы пользователь принадлежал к одной роли в списке разрешенных ролей, разделенном запятыми, к которому у него был бы доступ, независимо от порядка или количества ролей в списке разрешенных. Отсюда, я думаю, я не знаю, почему все не будет действовать одинаково… вы могли бы декомпилировать систему. откройте веб и посмотрите, как работает процедура авторизации, если вы действительно хотите разобраться в деталях, но для этого вам понадобится декомпилятор, такой как Reflector или Boomerang.

5. помогло ли это ответить на ваш вопрос? Или вам нужна дополнительная помощь с этим?

Ответ №2:

Попробуйте вместо этого выполнить это программно, как упоминалось ранее. если (Пользователь.IsInRole(«RoleC»)) { … и т.д. }

Комментарии:

1. Я рассматриваю это как обходной путь, хотя на самом деле это не отвечает на мой вопрос.