Как мы знаем, HTTP — протокол, на котором построена сеть, не имеет состояния — это означает, что каждая транзакция с сервером ничего не знает о предыдущих транзакциях. Чтобы обойти это, мы используем куки для отслеживания сеанса и эмуляции состояния. По сути, файл cookie хранится на компьютере пользователя, который предоставляет ключ, который сервер может использовать для получения любой информации о сеансе.
В предыдущих версиях Rails у нас было несколько вариантов хранилищ сессий — PStore, ActiveRecordStore, DRbStore и MemoryStore. PStore всегда был по умолчанию, в котором данные сеанса сохранялись во временном файле. Эта схема имела ряд ограничений, таких как состояние гонки в определенных ситуациях (то есть, если два экземпляра пытались записать в один и тот же сеанс одновременно, ваши данные могли бы быть захвачены — сохраняя большую информацию из множества AJAX вызовы — одна из причин), а также проблемы с масштабированием — использование нескольких серверов практически невозможно с помощью PStore.
В результате большинство производственных систем будет использовать одно из других хранилищ, в частности ActiveRecordStore, которое хранит все данные сеанса в системной базе данных.
Чтобы обойти эти ограничения в PStore, Rails 2.0 представит новое хранилище по умолчанию: CookieStore, которое хранит всю информацию о сеансе в одном или нескольких файлах cookie на клиентском компьютере. Для любого беглого взгляда это может показаться угрозой безопасности, и это может быть — однако есть несколько вещей, которые вы можете сделать как разработчик, чтобы сделать процесс намного более безопасным.
Прежде всего, позвольте мне указать, что хранилище не хранится в виде обычного текста — в файле environment.rb есть новый ключ подделки, для которого вы должны задать длинную случайную строку. Информация о сеансе хэшируется с этим ключом, поэтому сервер может проверять попытки подделки. Итак, первый шаг — убедиться, что этот ключ достаточно длинный и случайный.
Во-вторых, не храните конфиденциальную информацию в хэше сеанса. Большинство приложений могут обойтись только сохранением идентификатора пользователя. Это лучшая практика — и не только Rails-ориентированная.
В-третьих, если вы особенно параноик, посмотрите на один из других вариантов хранилища сеансов. CookieStore действительно является опцией наименьшего общего знаменателя, и один из других типов магазинов, вероятно, в любом случае больше подойдет для производственных систем. Вы можете увидеть описания других типов магазинов в блоге Скотта Баррона . Он также сравнивает различные типы магазинов (обратите внимание, что, поскольку статья уже устарела, новый Cookie Store не включен в тесты).