Я должен использовать встроенного поставщика членства для.NET ASP приложение MVC?
Я использовал пользовательского поставщика членства для аутентификации во всех моих приложениях веб-формы до настоящего времени. Я собираюсь начать разрабатывать свой первый веб-сайт с помощью MVC. Я задаюсь вопросом, должен ли я я использовать встроенного поставщика членства, который поставляет с ASP.NET MVC, или если я должен создать свое собственное. Мой сайт должен интегрироваться с открытым, Facebook, Google и т.д. для аутентификации и openauth для доступа API. Я задаюсь вопросом, как легкий это должно было бы использовать встроенный для моих потребностей.
4 ответа
Лично я ненавижу использовать ASP.NET Membership provider, который доступен в основном фреймворке ... когда он персистирует в базу данных SQL SERVER. Все таблицы и представления - это излишество для одного сайта. Для хостинговой компании? ... может быть... но для всех корпоративных сайтов, которые я делал... это было чертовски излишне и хлопотно. Что касается собственно интерфейса провайдера и т.д. ... он очень хорош ... но все еще очень хардкорен и т.д. Для простых и средних сайтов, IMO, это излишество.
Поэтому лично я бы использовал простой пользовательский код для обработки сохранения членства для большинства сайтов среднего уровня.
Затем это переходит ко второму вопросу: OpenId. Используйте DotNetOpenAuth .NET framework Эндрю Арнотта -> он просто надирает серьезную задницу (tm). Его использование не зависит от того, КАК вы сохраняете данные о членстве пользователя в хранилище. Т.е. если вы используете Sql Server + ASP.NET Membership provider, вы все равно можете (и должны) использовать DotNetOpenAuth. Если у вас есть простой, пользовательский способ сохранения данных пользователя в базе данных (что я и делаю), вы также можете использовать DotNetOpenAuth - эти два способа независимы друг от друга.
Итак, IMO, не используйте слишком сложный ASP.NET Membership + Sql Server, а используйте простую таблицу или две для сохранения данных пользователя. Далее, вы ДОЛЖНЫ использовать DotNetOpenAuth для любых OpenId вещей (StackOverflow использует DotNetOpenAuth для обработки своего OpenId логина).
Удачи :)
(Я уверен, что мои предложения по использованию ASP.NET Membership provider + Sql Server для сохранения информации вызовут у некоторых людей ярость).
Если вам нужно спросить, вы не должны писать своего собственного провайдера. Обеспечить безопасность действительно сложно . Сделать что-то неправильно невероятно легко.
Но хорошая новость заключается в том, что то, что вы хотите, невероятно распространено, и есть проверенные готовые инструменты, которые уже делают это. Например, Жанрейн . Есть и другие. По возможности используйте уже имеющийся, проверенный инструмент.
Посмотрите, что происходит с NerdDinner . Недавно (6 месяцев назад) они интегрировались с OpenID, с Google, Yahoo в качестве рекомендуемых провайдеров. Они по-прежнему разрешают все свои «родные» логины. Вот пример сайта, позволяющего пользователю аутентифицироваться разными способами.
Если вы сможете отразить некоторые из их функций, вы сможете использовать Facebook, OpenAuth и т.д. этой реализации.
Вот вариант, который я успешно использую.
По сути, у вас есть один пользователь, который может быть аутентифицирован несколькими способами.
Использование встроенного провайдера, который вы, конечно, можете поменять в любое время, не исключает возможности аутентификации этого пользователя несколькими способами.
Когда пользователь аутентифицируется с помощью OpenID, Facebook и т.д., сопоставьте этот логин с таблицей, которая сопоставляет конкретный метод входа и идентификацию с идентификацией Forms, и просто установите пользователя как вошедшего в систему с его каноническим именем пользователя Membership.
Если новый пользователь авторизуется на вашем сайте и не имеет учетной записи, просто создайте ее в провайдере членства автоматически. Установите пароль на случайный мусор, потому что они никогда не будут его использовать. Позвольте им и дальше ассоциировать с ним несколько типов входа.
Если пользователь хочет иметь прямой логин, просто используйте стандартные механизмы сброса пароля провайдера членства и предоставьте им его.
Короче говоря, пока что используйте встроенный механизм. Это не помешает вам делать то, что вы хотите.