ASP.NET аутентификация MVC с помощью пользовательской базы данных вместо ASPNETDB?

Если вы используете инструмент построения, тогда попробуйте Rucksack.

В противном случае вы можете использовать переменные CSS (пользовательские свойства), чтобы легко управлять размерами минимального и максимального шрифтов, например ( demo ):

* {
  /* Calculation */
  --diff: calc(var(--max-size) - var(--min-size));
  --responsive: calc((var(--min-size) * 1px) + var(--diff) * ((100vw - 420px) / (1200 - 420))); /* Ranges from 421px to 1199px */
}

h1 {
  --max-size: 50;
  --min-size: 25;
  font-size: var(--responsive);
}

h2 {
  --max-size: 40;
  --min-size: 20;
  font-size: var(--responsive);
}

26
задан devuxer 13 January 2010 в 19:30
поделиться

5 ответов

Все довольно просто, вам нужно вывести MembershipProvider и реализовать метод ValidateUser. Взгляните на этот пост . Я использую пользовательский провайдер членства с Postgres и MVC просто отлично.

16
ответ дан 28 November 2019 в 07:40
поделиться
  1. Нет. И я подозреваю, что большинство людей не доверяют этому грубому механизму

  2. Совсем немного, особенно если у вас уже есть стол.

  3. Взгляните на это, например: http://forums.asp.net/t/1250726.aspx

1
ответ дан UpTheCreek 28 November 2019 в 07:40
поделиться

Мы выполняем именно это в одном из наших приложений, и найти его довольно просто. У нас есть служба аутентификации (вызываемая от контроллера), которая обрабатывает механику хеширования введенного пароля, чтобы увидеть, является ли это совпадением, то просто возвращает Bool для метода, который мы называем «ISVALDLOGON».

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

Мы полностью проигнорировали AspnetDB полностью. Если мы получим действительный ответ от нашего проверки пользователя / пароля, мы просто называем стандартные формы формации .edirectirectFromLoginPage (имя пользователя, CreateCookiebool);

Надежда, которая поможет.

1
ответ дан 28 November 2019 в 07:40
поделиться

Просто строить то же самое, поэтому ответ на 1 должно быть :) Я использую стандартную аутентификацию стандартных форм ASP.NET, где я использую метод formbauthauthentication.redirectfromloginpage (имя пользователя, createCookiebool) для регистрации пользователя в. Я дал пользователю уникальный GUID (вы можете использовать любой другой идентификатор пользователя), и я храним его в параметре имени пользователя вместе с именем пользователя (для отображения на MasterPage: HTML.Encode (Page.user.identity.name.split («|» .TOBARARRAY ()) [1]))

В каждом контроллере / методе, в котором я должен знать, какой пользователь вошел в систему (через user.identity.name, разделить строку и получить userguid). Также я украсим эти процедуры с атрибутом [авторизации].

1
ответ дан 28 November 2019 в 07:40
поделиться

Я отвечу на ваши обновленные вопросы:

Нужно ли мне написать свой собственный MembershipProvider?

Если Вы (a) хотите продолжать использовать Аутентификацию форм, и (b) имеете структуру таблицы авторизации, которая не следует тем же конвенциям, что и ASPNETDB, то да. Если Вам не нужны FormsAuth (см. ниже), то Вы можете полностью отказаться от MembershipProvider, но я бы не рекомендовал это. Или, если Вы используете те же таблицы безопасности, что и ASPNETDB, но просто хотите указать на другую базу данных, Вы можете продолжить использование провайдера по умолчанию и просто изменить его конфигурацию.

Какие изменения нужно внести в мой файл web.config?

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

Будет ли атрибут [Авторизовать] работать, если я напишу свое собственное решение?

Да, если Вы придерживаетесь аутентификации форм (либо используйте AspNetSqlProvider, либо напишите и зарегистрируйте свой собственный провайдер членства). Нет, если Вы откажетесь от Аутентификации Форм (опять же, не рекомендуется).

Могу ли я использовать автоматически генерируемый AccountController с некоторыми незначительными изменениями или мне нужно переписать AccountController с нуля?

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

13
ответ дан 28 November 2019 в 07:40
поделиться
Другие вопросы по тегам:

Похожие вопросы: