С точки зрения архитектуры, что такое Session [] или Encrypted Cookies?

Question

Мы пытаемся выбрать наилучшее решение для поддержания состояния нашего веб-приложения. Мы склонны использовать Зашифрованные куки в браузере, но некоторые наши разработчики считают, что нам следует использовать переменные Session на сервере.

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

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

Что вы думаете по этой теме?

РЕДАКТИРОВАТЬ 1:

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

Answer 1

Здесь есть две проблемы. Во-первых, это разница между куки и сессией. Если вы не используете сеансы без файлов cookie (например, уникальные идентификаторы в URL), сеанс - это файл cookie с очень коротким сроком действия. Вы можете легко настроить приложение для совместного использования сеанса на нескольких серверах, используя сервер состояний ( ScaleOut , Скорость , SQL Server )

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

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

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

Запоминание пользователя с cookie :

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

Преимущество использования собственной функции сеанса / «помни меня» на основе файлов cookie заключается в том, что она дает больше контроля над тем, как долго информация сохраняется, распространяется и т. Д. С другой стороны, она представляет собой большую работу, некоторые из который повторно реализует функциональность, которая поставляется с ASP.NET Session. Обычно я рекомендую использовать то, что уже есть, если вы не можете четко сформулировать некоторые требования к ведению бизнеса, которые исключают это как вариант.

Answer 2

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

1. Масштабируемость от низкого до среднего. Балансировка нагрузки с помощью липких сеансов или балансировка нагрузки на основе IP-адреса запроса (и все еще с использованием сеанса ASP.NET).
2. Масштабируемость от средней до высокой: общее хранилище сессий в оперативной памяти, т.е. общий ASP.NET StateService, проект "Velocity", ScaleOut SessionServer и т. Д.
3. Высокая масштабируемость: самодельная система сеансов на основе файлов cookie, которая полностью «не имеет состояния» между веб-серверами, в том смысле, что она основана на предварительных общих секретах и ​​хешах, которые проверяются без запроса центрального хранилища сеансов. Если вы идете по этому пути, то вам следует также рассмотреть возможность сохранения нечувствительных пользовательских настроек в файле cookie, чтобы также масштабировать их.

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

Ask Бьёрн Хансен имеет обзор сеансов в файлах cookie на этих слайдах презентации, начиная со слайда 16 и далее . Тео Шлосснагл написал о них в своей книге «Масштабируемые интернет-архитектуры» . Вот хорошая научная статья о создании действительно безопасных файлов cookie, с более высокой безопасностью, чем предложения Аска и Тео, если мне не изменяет память.

Обратите внимание, что вам может не понадобиться такая большая масштабируемость, как вы думаете. Например, переполнение стека обслуживается только двумя веб-серверами, а балансировщик нагрузки разделяет трафик по IP-адресу пользователя. Благодаря этому локальный сеанс ASP.NET на каждом веб-сервере интерфейса работает в обычном режиме, если все веб-серверы работают - приемлемое и очень простое решение для большинства сайтов с 2-5 веб-серверами.

Существует одно соображение, которое может отменить вышеупомянутое. Если вы обнаружите, что вам нужен общий кэш для других данных (результаты SQL-запроса, результаты многоразового использования, но с очень большой ЦП дорогостоящие вычисления), и вы уже собираетесь реализовать такой кэш , тогда имеет смысл только вставлять сессии в этот кеш. Примерами типа общего кэша, о котором я говорю, являются Memcached , Microsoft , проект "Velocity" , Shared Cache , ScaleOut StateServer и другие. Многим сайтам это не понадобится, но это очень хорошее решение. Это решение может стать более доступным с точки зрения цены и времени разработки после выпуска проекта «Velocity», в зависимости от намерений Microsoft с «Velocity».

Заключение

1. Вам нужны только сеансы, совместно используемые веб-серверами, или это нужно и для других данных (кеширование результатов SQL и т. Д.)? Вам нужен общий кэш в оперативной памяти в целом? Если это так, вам придется в целом изучить промежуточное программное обеспечение общего кэширования / кластеризации.
2. Если нет, знаете ли вы, в каком масштабе вы будете работать? Если вы это сделаете, то сможете решить, какой из 4 вариантов данных сеанса (от встроенного сеанса ASP.NET до файлов cookie) вам больше подходит.
3. Если вы только начинаете и не знаете, сколько пользователей вы привлечете, тогда я начну со встроенной функциональности сеанса ASP.NET и добавлю более сложные решения позже, когда возникнет такая необходимость.

Answer 3

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

Answer 4

Традиционный подход - Session, поддерживаемый SqlSessionStateProvider.

Современный подход, по-видимому, заключается в использовании базы данных для хранения и использовании кэша (memcached) перед базой данных для ускорения поиска. Но сеанс отсутствует, как и зашифрованные файлы cookie (за исключением файла cookie для проверки подлинности).

Answer 5

, если пользователь очистит куки-файлы от информации о браузере, то наверняка будет утерян. Это не относится к сеансу

Answer 6

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

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

Если вы идете по пути cookie, вам нужно быть очень осторожным в том, как вы это делаете, и если вы не эксперт, вы почти наверняка сделаете что-то не так.