Ruby on Rails в течение некоторого времени поддерживала подписанные сеансы на основе файлов cookie с несколькими зашифрованными реализациями возникает с тех пор. Python и PHP также имеют реализации.
Существует ли такой зверь для контейнеров сервлетов Java Jetty или Tomcat?
Мы получили значительный прирост производительности за сеансы на основе RDBMS с реализацией PHP в нашей кластерной среде, и мне было бы интересно попробовать что-то подобное с одним из наших приложений Java (в котором в настоящее время используется Jetty 7).
Я знаю другие способы достижения этой цели (memcached, синхронизированная в памяти кеши), но я считаю, что для наших конкретных нужд ограничения этого метода хранения (завершение сеанса до выхода, эффективное хранилище после ограничения размера файла cookie 4K, зависимость от сверхсекретного серверного ключа) перевешиваются более простым среды развертывания для этого конкретного приложения.
Если реализация не существует, есть ли у кого-нибудь идеи, почему это не так? (например, сеансы Java обычно больше 4K и, следовательно, не поддаются такому методу хранения)
Мы внедрили Session-In-Cookie и успешно использовали его в кластере Tomcat, чтобы обеспечить совместное использование сеанса среди 20 узлов и, таким образом, включить развертывание с нулевым отключением. Я только что написал первую часть двухсерийной серии по реализации здесь: http://blog.shinetech.com/2012/12/18/simple-session-sharing-in-tomcat-cluster-using-the-session-in-cookie-pattern/. Эта часть посвящена основной реализации, аспекты безопасности будут рассмотрены во второй части.
Я не знаю ничего в любом контейнере, который бы сериализовал HttpSession для cookie для вас. Вы могли бы достичь такого уровня, выполнив Filter, который сможет сериализовать состояние сеанса в cookie при ответе на веб-клиент и десериализовать его по запросу. Вы по-прежнему связаны с ограничениями cookie на стороне клиента, и вам следует внимательно рассмотреть последствия для безопасности состояния, в котором вы храните клиентскую часть, и/или насколько вы доверяете клиенту, представляющему файл cookie.
Кажется, здесь есть два вопроса:
В отношении первого вопроса: Да, в зависимости от размера графика сеанса (глубокое вложение всех переменных/объектов сеанса) ограничение размера файла cookie (которое фактически является ограничением заголовка HTTP) является существенным фактором. Если граф сеанса аккуратно вписывается в ограничение HTTP-заголовка (которое в некоторой степени настраивается на стороне веб-сервера) и/или может быть дополнено параметрами запроса URL-адреса на основе REST (чтобы облегчить часть информации о состоянии на сервере)... тогда возможна реализация cookie. Однако это было бы программным и управляемым контейнером.
Относительно второго вопроса: обеспечение безопасности - это еще один вопрос. Печально известный общий файл cookie JSESSIONID в системах Java/J2EE - это простой токен-ключ для сеанса в памяти или на диске с кэшем на сервере приложений. Это всего лишь ключ карты. С помощью этого ключа любой может украсть или выдавать себя за сеанс пользователя. Вероятно, это одна из самых слабых ссылок во всем аппарате сеанса, управляемом контейнером. Существуют коммерческие продукты с защитой от сеансов, которые предотвращают захват сеанса при хищении файлов cookie, предотвращают повторные атаки (которые могут победить SSL, захватывая повтор зашифрованного сеанса входа в систему для получения сеанса) и других векторов атак. Один из продуктов, о которых я знаю, может сделать это без изменений кода (через фильтр безопасности). Тем не менее, мне неизвестны какие-либо общие рамки или инициативы с открытым исходным кодом для подключения этой дыры, вероятно, потому, что для этого требуется уровень знаний, который выходит за рамки общей разработки приложений.