Как создать куки для входа? Или я должен придерживаться членства в asp.net?

Question

Я использую asp.net MVC с членством asp.net, но я начинаю думать, что нет смысла использовать членство Asp.net.

Итак, я хотел бы выяснить, как генерировать файлы cookie того же типа с теми же полями и с тем, которое делает членство в asp.net.

Также есть ли другие настройки, которые мне нужны? Например, как насчет работы типа «User.Identity.Name»? Например, где это устанавливается? Это взято из печенья или что? Или это из-за чего-то другого?

То же самое с "Page.User.Identity.Name".

Устанавливает ли членство в asp.net что-либо еще, о чем я не знаю, что может испортить такие вещи, как тег авторизации в asp.net MVC?

Я не очень понимаю, как работают логин / аутентификация и тому подобное, поскольку я всегда использовал членство в asp.net.

---

Читайте ниже, почему, если вы хотите знать, почему я думаю о том, чтобы отказаться от членства в asp.net

---

Мне нравится членство в asp.net и его удобно использовать, если вам, кажется, не нужно вносить в него много изменений или вам нужно что-то быстрое.

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

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

Дальше, даже если ты справишься со всем этим, у меня все еще будет эта проблема? Я разрешаю дубликаты userNames, так как у меня есть простые способы определить, какой пользователь, какой, просматривая другие поля. Мне нужны повторяющиеся имена пользователей, в противном случае я могу увидеть потенциальные проблемы.

Так что из-за этих повторяющихся имен я даже не могу загрузить веб-сайт администратора членства asp.net, так как он возвращается с ошибкой о повторяющихся именах.

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

Итак, эти причины и тот факт, что у меня есть свой собственный метод для всего, что мне нужно (уже написано), и я не использую какой-либо встроенный метод из членства asp.net, я думаю, что я должен просто отбросить его и освободиться от его ограничения.

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

Answer 1

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

Первое, что вам нужно сделать, это создать страницу входа. Здесь вы реализуете функцию проверки имени пользователя и пароля пользователя (или сертификата, или как они могут войти). Затем вы сохраняете cookie, представляющий имя пользователя. AFAIK, членство asp.net хранит зашифрованную версию имени пользователя пользователя. ИМХО это не очень безопасно, потому что хакер должен знать только ключ компьютера сервера, чтобы выдать себя за любого пользователя на сайте. Я лично использую System.Security.Cryptography.RandonNumberGenerator для генерации длинного двоичного токена для пользователя, который я сохраняю в таблице вместе с идентификатором пользователя. Затем этот токен передается пользователям в файле cookie.

Теперь вам нужно реализовать событие Application_AuthenticateRequest. Здесь вы читаете cookie, а затем проверяете, соответствует ли этот cookie действительному пользователю. Таким образом, вы устанавливаете для свойства HttpContext.Current.User значение IPrincipal. В фреймворке есть простая реализация IPrincipal, GenericPrincipal. Этот объект также содержит роли пользователя.

Все, что связано с аутентификацией и аутентификацией после этого, проверяется только в HttpContext.Current.User. Так что это означает, что Page.User установлен в значение, которое вы установили. Если у вас установлен уровень безопасности на уровне каталога, то есть, возможно, только определенные роли могут обращаться к определенной папке в веб-приложении, которая будет работать и т. Д.

На самом деле это старый метод проверки подлинности форм из .net 1.0. Членство - это просто построение слоя поверх аутентификации форм.

Answer 2

Все, что вам нужно при успешном входе в систему, чтобы создать cookie:

FormsAuthentication.SetAuthCookie("username", false);

А когда вам нужно выйти, просто используйте:

FormsAuthentication.SignOut();

User.Identity.Name будет работать, потому что он ищет cookie аутентификации и, если он отправляется вместе с запросом, он расшифровывает его и читает имя пользователя, которое хранится внутри. Вы можете использовать что угодно для аутентификации и авторизации пользователя.

Answer 3

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

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

У нас было пару дней назад очень похожее обсуждение: Можно ли создать систему входа в систему с ASP.NET MVC, но не использовать MembershipProvider?