Состояние веб-аутентификации - сеанс или файл cookie?

Question

Каков наилучший способ аутентификации и отслеживания состояния аутентификации пользователя от страницы к странице?Кто-то говорит о состоянии сеанса, кто-то говорит о файлах cookie?

Могу ли я просто использовать переменную сеанса, которая имеет идентификатор пользователя, и после аутентификации создать пользовательский пользовательский класс, содержащий информацию о пользователе.Затем на каждой странице проверяйте, что переменная сеанса все еще активна, и получайте доступ к основным пользовательским данным из объекта User?

Есть какие-нибудь мысли?Есть какие-нибудь хорошие примеры?

Answer 1

Там нет никакого Идеальный способ сделать это.Если вы храните его в печенье, вы рискуете, что печенье могут украсть.Если вы сохраните его в сеансе, вы попадете в ловушку, потому что сеансы могут быть перехвачены.

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

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

Answer 2

Проблема с предпочтением сеансов файлам cookie для "безопасности" заключается в том, что сеансы ИСПОЛЬЗУЮТ файлы cookie для идентификации пользователя, поэтому любая проблема с файлами cookie присутствует при сеансах.

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

Поскольку вы используете .NET, вам в основном придется написать свой собственный провайдер хранилища сеансов, чтобы справиться с этим, поскольку InProc не будет масштабироваться дальше 1 сервера, поставщик БД - это просто плохая идея (весь смысл в том, чтобы ИЗБЕЖАТЬ чтения БД здесь при масштабировании, а не добавлять больше), а у сервера состояний много проблем с пропускной способностью.(В прошлом я с некоторым успехом использовал провайдера хранилища сеансов memcached для борьбы с этой проблемой).

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

Answer 3

Я не знаю, ЛУЧШИЙ ли это способ сделать это, но нас устраивает то, как мы это делаем.

у нас есть пользовательский объект user, который мы создаем, когда пользователь проходит аутентификацию, затем мы используем Session для обслуживания этого объекта во всем приложении.

В некоторых приложениях мы комбинируем это с использованием файлов cookie для непрерывного продления сеанса.

Answer 4

Файлы cookie и сеансы сами по себе на самом деле недостаточны.Это инструменты для отслеживания пользователя и того, что он делает, но вам действительно нужно подумать об использовании базы данных для сохранения информации о пользователе, которая также может быть использована для защиты приложения.

Answer 5

Сеансы - это файлы cookie...