Роли для доступа к сервису White Label

Хорошо,

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

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

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

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

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

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

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

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

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


person saurabhj    schedule 31.03.2009    source источник


Ответы (1)


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

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

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

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

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

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

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

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

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

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

    1. Method IsInRole of this type should look take current site (from HttpRequest) look into the site-user table and get roles
  5. Затем вы должны связать своего принципала с запросом. Сделайте это в событии PostAuthenticateRequest.

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

person XOR    schedule 31.03.2009
comment
На самом деле нам определенно нужно место, где мы можем перечислить сайты -> информация о пользователях. Следовательно, даже если мы не используем роли, нам может понадобиться создать таблицу, в которой будет храниться эта информация. Наше решение использовать роли было вызвано тем фактом, что .Net имеет множество встроенных методов для ролей, которые мы могли бы использовать напрямую. - person saurabhj; 31.03.2009
comment
Мы не рассматривали возможность разделения мини-сайтов на отдельные приложения, но я считаю, что это вызовет еще больше проблем (учитывая, что пользователь может иметь доступ к нескольким веб-сайтам только с одним логином). - person saurabhj; 31.03.2009
comment
Я согласен, что приложение - плохая идея. Сейчас я посмотрю наш код и дам вам больше информации. Возможно, нет необходимости делать новый модуль авторизации. Пользовательского членства и поставщиков ролей будет достаточно. - person XOR; 31.03.2009