Сохранить информацию о сеансе в ASP.Net Cookie или Session State? - PullRequest
6 голосов
/ 17 января 2012

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

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

Что вы думаетелучший подход для такого рода данных?

Ответы [ 4 ]

5 голосов
/ 17 января 2012

Первый вопрос, который я задаю себе о данных сеанса: они мне действительно нужны?Помните, что веб не имеет состояния, поэтому, возможно, вы сможете изменить свое приложение, чтобы не использовать состояние сеанса.Для сеансов требуется много ресурсов управления и сервера.

Между тем у вас есть два решения:

  • , поскольку вы находитесь в ферме, поместите сеанс на SQL Server, конфигурируя состояние сеанса вweb.config (он требует ресурсов и немного медленнее, но это самый безопасный способ хранения данных сеанса, чтобы гарантировать, что пользователь не сможет их изменить)

  • добавить механизм шифрования / дешифрования в ваш файл cookieс закрытым ключом сервера

4 голосов
/ 17 января 2012

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

Состояние сеанса ASP.NET является приемлемым решением для вашей проблемы, хотя есть некоторые предостережения относительно ферм серверов.В этой статье MSDN объясняется, как заставить Session State работать в среде вашей фермы серверов.Ответ Be.St. касается предлагаемого внепроцессного подхода.

Третий вариант - создать хранилище сеансов, управляемое базой данных, которое не обязательно зависит от состояния сеанса.Я нахожу Session State немного хлопотным с различными средами развертывания (например, фермами серверов), поэтому иногда я буду использовать этот подход.Затем вы можете получить доступ к этим данным, прикрепив ключ сеанса к строке запроса или сохранив ключ сеанса в файле cookie (все еще потенциально изменяемый пользователем, но с меньшей вероятностью являющийся целью для такого действия).

2 голосов
/ 17 января 2012

Лично я считаю, что лучше хранить информацию в cache, хотя вы вполне могли бы сохранить ее в session или зашифровать ее и сохранить в cookie, и это просто вопрос личных предпочтений.

Причина, по которой я предпочитаю cache, заключается в том, что он не уязвим для перехвата сеансов, поэтому пользователь не может изменить его так, как он хранится на сервере (так же, как session в этом отношении).

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

Код для хранения дополнительной пользовательской информации в кеше: Является ли этот пользовательский принципал в базовом контроллере ASP.NET MVC 3 ужасно неэффективным?

РЕДАКТИРОВАТЬ: И причина, по которой я предпочитаю хранить эту информацию где-то рядом вДело в том, что я не хочу все время пресекать базу данных, так как это очень неэффективно.

1 голос
/ 17 января 2012

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...