ASP.NET MVC3: мне нужно использовать MembershipProvider?

Question

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

Я все еще использую архитектуру AccountController по умолчанию, но я довольнобыстро определил, что я не хочу использовать aspnetdb.mdf для аутентификации, так как его дизайн сильно отличается от моих требований.Я действительно хочу аутентификацию на основе ролей, поэтому я в конечном итоге написал пользовательские классы User и Role в качестве классов Entity, использующих код, и использовал этот учебник для настройки пользовательских MembershipProvider и RoleProvider.

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

Все арендаторы используют одну базу данных.Каждая сущность имеет свойство Tenant, которое определяет, кому она принадлежит.

Итак, вот проблема:
Имена пользователей не должны быть глобально уникальными.Только комбинация имени пользователя и арендатора должна быть уникальной.Таким образом, ValidateUser должен знать имя пользователя, пароль и владельца .Поскольку мой пользовательский MembershipProvider не является контроллером, он не знает, какой арендатор использует сеанс, а метод ValidateUser принимает только имя пользователя и пароль, поэтому я не могу передать ему эту информацию.

Более того, в значительной степенивсе, что делает MembershipProvider, кроме ValidateUser, уже реализовано в классе UserRepository, что и было сказано в этом руководстве.Мне скорее нравится шаблон Repository, и он гораздо удобнее, чем привязка к интерфейсу MembershipProvider, но теперь существует огромный конфликт интересов между UserRepository и MembershipProvider.

Итак, мой вопрос:
Нужно ли вообще использовать MembershipProvider или даже Membership?
Кажется, что все, что делает MembershipProvider, будет выполняться более удобным для моего класса репозитория.На данный момент все, что мне нужно сделать, это написать новый атрибут Authorize, который не зависит от членства, и все должно работать без членства вообще, верно?Если я не отказываюсь от членства, я вынужден полностью изуродовать мою реализацию MembershipProvider до такой степени, что она все равно почти не похожа на оригинальный интерфейс.

... Либо это, либо членство делает массу вещей, которые яне осознавать и устранять это явная глупость.Это также отличная возможность.

Answer 1

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

Аналогично, система ролей только назначает имя роли пользователю.

В конечном счете, членство и роли являются всего лишь реализациями интерфейса IPrincipal.Тогда как FormsAuthentication является реализацией интерфейса IIdentity.Они работают вместе, так что вы можете использовать встроенную систему авторизации и аутентификации ASP.NET.

Членство на самом деле имеет концепцию нескольких арендаторов.Эта функциональность осуществляется через поле «ApplicationNane» таблицы aspnet_users (также устанавливается в самом классе Membership)

Из документации по классу Membership:

Используется ApplicationNameидентифицировать пользователей, специфичных для приложения.То есть одно и то же имя пользователя может существовать в базе данных для нескольких приложений ASP.NET, в которых указано другое имя приложения.Это позволяет нескольким приложениям использовать одну и ту же базу данных для хранения пользовательской информации, не сталкиваясь с дублирующимися конфликтами имен пользователей.Кроме того, несколько приложений ASP.NET могут использовать одну и ту же базу данных пользователей, указав одно и то же имя приложения.ApplicationName может быть задано программно или декларативно в конфигурации для веб-приложения.

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

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

Это в основном позволит вам использовать стандарт внепровайдера коробочного членства без каких-либо изменений.Вы просто не должны охранять вызовы доступа.

Answer 2

Вам вовсе не обязательно использовать поставщика членства. Его просто предоставили как быстрый и последовательный способ начать работу. Некоторые выбирают его, потому что он поддерживает несколько баз данных (универсальные поставщики членства включают в себя azure, а также sql ce, express и full), но для других, пытающихся сопоставить его с вашими приложениями, правила могут быть более сложными, чем <5 строк кода, которые требуются для аутентифицируйте и выдайте свой собственный билет авторизации форм. </p>

С учетом вышесказанного я предполагаю, что вы используете проверку подлинности с помощью форм. Вы можете просто оформить билет самостоятельно. Я бы все еще программировал для интерфейса, который должен иметь шаблон MVC по умолчанию, поэтому просто добавьте новый идентификатор арендатора.

С учетом сказанного я бы подумал о том, чтобы иметь уникальные имена. Это гарантирует, что вы не «забудете» выполнить дополнительную проверку арендатора где-то еще в приложении, и tenant1 \ userBip и tenant2 \ userBip неожиданно в конечном итоге будут топать записи друг друга.

Правда, тестирование должно раскрыть это - если тестирование завершено:)