#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. Я рассматриваю это как обходной путь, хотя на самом деле это не отвечает на мой вопрос.