От точки зрения Архитектуры, Что такое лучшая Сессия подхода [] или Зашифрованные Cookie?

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

9
задан Rex M 23 September 2009 в 00:31
поделиться

5 ответов

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

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

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

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

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

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

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

5
ответ дан 4 December 2019 в 19:35
поделиться

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

2
ответ дан 4 December 2019 в 19:35
поделиться

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

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

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

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

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

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

Заключение

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

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

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

1
ответ дан 4 December 2019 в 19:35
поделиться

Да, я подозреваю, что ваша обработка файлов cookie может быть беспорядочной.

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

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

0
ответ дан 4 December 2019 в 19:35
поделиться
Другие вопросы по тегам:

Похожие вопросы: