Написание собственного поставщика ролей для главных страниц / без Machine.Config - PullRequest
Новая
       9

Написание собственного поставщика ролей для главных страниц / без Machine.Config

2 голосов
/ 07 марта 2009

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

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

Ответы [ 2 ]

2 голосов
/ 07 марта 2009

Конфигурацию прав и самого провайдера можно определить в web.config. Чтобы применить права к различным дочерним страницам, вы просто блокируете страницы контента через узел Location.System.Web.Authorization в web.config (дополнительная информация здесь ).

Чтобы создать собственного провайдера, вы просто наследуете от абстрактного класса (System.Web.Security) RoleProvider и реализуете необходимые методы (обычно IsUserInRole, GetUsersInRole и GetRolesForUser, хотя в моей памяти сейчас немного туманно) что Asp.Net вызывает из коробки для авторизации на основе ролей, так что вы можете реализовать их все). Подробнее здесь .

Как только это будет сделано, вы зарегистрируете, какой поставщик использовать в web.config: 

<configuration>
  <system.web>
    <roleManager enabled="true"
      defaultProvider="YourRoleProviderHere">
      <providers>
        <add name="YourRoleProviderHere"
          type="YourRoleProviderHere, YourRoleProviderAssembly"
          description="Your totally awesome role provider"
        />
      </providers>
    </roleManager>
    ...

Это настроит ваше приложение на использование вашего поставщика ролей, и практически без работы у вас все работает. Все стандартные методы авторизации все еще работают (User.IsInRole), и вы интегрированы с Asp.Net.

0 голосов
/ 18 мая 2009

Вы также можете попробовать использовать HttpModule : - Измените код в примере приложения, чтобы запрос знал, какая страница должна быть запрошена - очевидно, вам потребуется следующая структура DbTables: - Эта ссылка даст вам хорошее начало

Теперь эти грубые операторы создания таблицы дадут вам следующий набор:

  • каждый пользователь будет иметь одну или несколько пользовательских ролей
  • каждая страница будет настраиваемой для доступа к каждой пользовательской роли

Некоторые DDL SQL вокруг идеи: 

CREATE TABLE [User](
    [UserId] [int] IDENTITY(1,1) NOT NULL,
    [FirstName] [varchar](100) NOT NULL,
    [SecondName] [varchar](100) NULL,
    [LastName] [varchar](100) NOT NULL,
    [DomainName] [varchar](100) NOT NULL,
    [UserRoleId] [int] NOT NULL,
    [Password] [nvarchar](100) NOT NULL
) ON [PRIMARY]

GO

 CREATE TABLE [dbo].[UserRole](
    [UsersRoleId] [int] IDENTITY(1,1) NOT NULL,
    [RoleId] [int] NOT NULL,
    [UserId] [int] NOT NULL
) ON [PRIMARY]



 CREATE TABLE [ga].[Roles](
    [RoleId] [int] IDENTITY(1,1) NOT NULL,
    [RoleName] [varchar](50) NOT NULL,
    [RoleDefinition] [varchar](1000) NULL
) ON [PRIMARY]

GO

 CREATE TABLE [dbo].[Page](
[PageId] [int] IDENTITY(1,1) NOT NULL,
[PageName] [varchar](200) NOT NULL,
[PageDescription] [varchar](max) NOT NULL,
[PageTitle] [varchar](50) NOT NULL
) ON [PRIMARY]

GO


CREATE TABLE [dbo].[PagePerUserRole](
    [PageForRoleId] [int] IDENTITY(1,1) NOT NULL,
    [UserRoleId] [int] NOT NULL,
    [PageId] [int] NOT NULL
) ON [PRIMARY]

GO

ИЛИ CustomBaseClass

в основном то же самое, но проверяет, имеет ли использование доступ к какому-либо очень раннему событию жизненного цикла страницы asp.net, например, OnInit

Последнее является более неортодоксальным способом - все же я написал приложение, использующее усложняющий механизм аутентификации (использующий 3-ю программную систему), и оно, кажется, работает некоторое время в производстве; )

...