Роли для доступа к услуге с белой этикеткой

Question

ОК,

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

Что-то вроде Нин. Кроме того, у меня есть только 1 базовый вход и доступ к каждому мини-сайту предоставляется (прямо сейчас) через роли.

Так как я делаю это прямо сейчас:

Everytime новый мини-сайт создан - скажем, бла, я создаю 2 роли в моем приложении. blah_users и blah_admin

Пользователь создания мини-сайт отводится роль - blah_admin и любой другой пользователь хочет присоединиться к этому мини-сайт (или сеть) отводится роль - blah_user.

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

Проблема, с которой я столкнулась, заключается в том, что, выполняя роль системы на основе ролей, мне приходится делать множество вещей вручную. Элементы управления Asp.Net 2, которые работают с свойством User.IsAunthenticated, в наши дни бесполезны для меня, потому что наряду с свойством IsAuthenticated я также должен проверить, имеет ли пользователь правильную роль.

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

Этот сайт разрабатывается в ASP.Net 2 на IIS 6. Спасибо тонне!

Answer 1

Я боюсь, что стандартные роли, связанные с ролями ASP.NET, не то, что вам нужно. Вы можете попытаться изменить модуль аутентификации таким образом, чтобы он:

1. Запишите вас с помощью файла cookie.
2. Определите, какие роли у вас есть. Возможно, вы будете использовать специальную таблицу, соответствующую пользователю и сайту.
3. Внесите пользовательский принцип с перечислениями пользователей и назначьте Identity и Principal текущему запросу.

Я также не думаю, что создание особых ролей для каждого сайта - хорошая идея. Когда у вас будет сотня сайтов, у вас также будет 200 ролей. Боюсь, довольно неуправляемый.

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

Дополнение: Еще одна возможность для изучения - это приложение, которое существует в системе аутентификации ASP.NET. Может быть, можно изолировать каждый подраздел в отдельном приложении?

Обновление: Метод, который подходит для нашего применения.

1. Не делайте много клонированных ролей. Используйте только два пользователя и администратора. Если ваши сайты являются общедоступными, роль «пользователей» может быть просто глобальной - пользователь на одном сайте не отличается от пользователя на другом сайте. Если «пользователи» и «все» - разные роли, то, конечно, «пользователи» также должны быть привязаны к сайту.

2. Используйте стандартных пользователей членства в ASP.NET, но не используйте стандартный механизм роли.

3. Создать механизм для хранения связи между сайтом и пользователем. Это может быть простая таблица, в которой содержится идентификатор сайта, пользователь и роль.

4. Что вы должны переопределить - это метод IsInRole. (Метод s, если быть точным, я расскажу позже). Этот метод находится в интерфейсе IPrinciple, поэтому вам нужно создать свой основной объект. Это довольно просто.

   1. Метод IsInRole этого типа должна выглядеть принять текущем сайте (от HttpRequest) смотреть в таблицу сайт пользователей и получить роли

5. Тогда вы должны связать свой основной с просьбой. Сделайте это в событии PostAuthenticateRequest.

6. Существует также RoleProvider. Честно говоря, я не уверен, когда он используется, но у него также есть метод IsInRole. Мы можем переопределить его таким же образом. Но другие методы этого провайдера сложнее. Например, AddUsersToRoles. Он принимает массив имен пользователей и ролей, но в какой контекст (сайт) он должен быть добавлен? К текущему? Не уверен, потому что я не знаю, когда вызывается этот метод. Поэтому это требует некоторых экспериментов. Я вижу (Reflector помогает), что RopePrincipal сам по себе использует RoleProvider для извлечения списка ролей, поэтому, возможно, он реализует только RoleProvider с использованием стандартного принципала. Для нашего приложения это не так, поэтому я не могу сказать, какие проблемы можно скрыть здесь.