Поставщик членства в Microsoft Vs Custom Provider Vs Complete Custom Login System

Question

Я в настоящее время преобразовываю очень старый, но работающий классический ASP-сайт в ASP.Net.

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

Когда я спросил кого-то об этом, они сказали: «Вам нужно использовать Поставщика Microsoft» и прочитал лекцию о том, как Microsoft бесплатно освобождает все эти вещи и насколько они хороши, и их следует использовать как можно больше.

Я провел довольно много исследований по этому вопросу (в основном, глядя на видео на http://asp.net/learn), и меня очень впечатляют некоторые функции, поскольку, похоже, компоненты перетаскивания для элементов, которые потребуют от меня времени для записи ,

Однако текущая база данных членства сложна для объяснения, это полностью настраиваемая письменная база данных, которая имеет много внутренних отношений ... Она не совсем «совместима» с поставщиком Microsoft по умолчанию.

Я взглянул на How Do I: Create a Custom Membership Provider?, но я чувствую себя немного вне зоны комфорта и обеспокоен тем, что он будет либо медленным, либо внедрить дыру в безопасности, либо просто не сработает.

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

Мне просто интересно, что бы вы сделали, если столкнулись с подобной ситуацией?

1. Использование поставщика членства Microsoft и каким-то образом заставить его работать на вас (хотя я хотел бы предложения)

2. Используйте поставщика членства Microsoft, но использовать пользовательский поставщик, который настроенное вокруг вашего кода.

3. Используйте свое собственное решение под заказ?

Answer 1

Это видео действительно усложнять :) Если вы собираетесь реализовать пользовательский поставщик, то рефлектор поверх существующей является хорошим местом для начала :)

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

Если вы думаете об этом, дистанционное предоставление услуг на самом деле не принадлежит провайдеру членства, это не является функцией членства. Все членство в нем предоставляет пользователям имена и пароли и аутентификацию. Мое собственное чувство заключается в том, что вы должны переместить выделение услуг из него и выполнить его на сайте ASP.NET после того, как пользователь был создан - даже если это просто вызов хранимой процедуры, когда поставщик членства сделал свою работу. Если вы это сделаете, вы можете обнаружить, что поставщик членства в SQL сделает все, что вам нужно (возможно, с поставщиками профилей Roles &), и таким образом у вас есть меньше кода для написания!

Answer 2

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

Опасайтесь, что для этого не существует интерфейса управления ASP.NET «из коробки», вам нужно будет перевернуть свой собственный или использовать сторонний.

Answer 3

Я был в подобных ситуациях в прошлом. В обоих случаях мы создали пользовательские реализации поставщиков (MembershipProvider, RoleProvider, ProfileProvider) вокруг существующего механизма.

В обоих случаях мы использовали только реализации поставщика для доступа только для чтения, например. чтобы дать нам простые проверки gubbins в web.config и т. п. Код пользовательского администрирования остался наедине, поскольку он работал нормально.

Answer 4

Используйте мой специализированный MemberhipProvider для работы с моими собственными таблицами базы данных.