Где хранить информацию для входа пользователя в asp.net

Question

Когда я создаю приложения asp.net, требующие входа пользователя, я пишу метод в своем классе businees, который возвращает экземпляр объекта Member, если пользователь вошел в систему, и null, если нет. Затем я делаю это:

Session["User"] = user;

Затем при каждой загрузке страницы я должен реализовать это:

User user = Session["User"] as User;
if(null==user){
 //toggle the state of ascx, to show username/password boxes again,
 //Response.Redirect("somewhere else") etc...
}

Похоже, это работает, но это хороший подход? Потому что иногда Session больше не возвращает этот объект. Это происходит до 20 минут, что является тайм-аутом по умолчанию для сессии. Есть ли резон для этого? Это происходит случайно, когда я делаю несколько обратных передач во время тестирования.

Заранее спасибо.

Answer 1

Вы должны использовать Form Authenticacion, без каких-либо сомнений. Вот некоторые интересные ссылки:

• Как: защитить проверку подлинности с помощью форм в ASP.NET 2.0
• Использование проверки подлинности с помощью форм в ASP.NET

Answer 2

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

Answer 3

Лучший способ хранить информацию о пользователях в моем опыте - в базе данных. Microsoft делает это проще с SqlMembershipProvider . Это дает вам заранее определенную схему с лучшими практиками, такими как хранение хэшей паролей и с солью (НЕ В CLEARTEXT!). Это хорошее начало и настраиваемый. Ура!

Answer 4

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

Насколько велик ваш пользовательский объект? Если он не слишком велик, вы можете хранить данные в cookie, а не в состоянии сеанса. Silverlight изолированное хранилище является еще одним вариантом. В противном случае вы можете сохранить его в БД и самостоятельно управлять кешем. Это может быть намного эффективнее, чем использование словаря Session ....

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