2013-08-18 2 views
3

Tomcat по стандарту Java EE позволяет запросам указывать свой существующий идентификатор сеанса двумя способами: 1) через файл cookie; 2) через «параметр пути» (не регулярный параметр, параметр пути имеет формат http://host/path/file.ext;jsessionid=xxx?a=b&c=d... - обратите внимание на «;» и тот факт, что строка запроса начинается только после параметра пути). Что я хочу - передать идентификатор сеанса в запросе в качестве параметра REGULAR в строке запроса после «?», Например http://host/path/file.ext?jsessionid=xxx.Переопределение метода Tomcat для получения сеанса из запроса

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

Я знаю, что получение идентификатора сеанса таким образом нестандартно; Я знаю, что использование файла cookie или параметра пути - это БОЛЬШИЕ способы отслеживания состояния сеанса; Я знаю, что размещение идентификатора сеанса в строке запроса представляет собой потенциальные проблемы. Мне все равно нужно это сделать.

Запуск Tomcat 7, кстати.

+0

У вас, кажется, есть все основания для этого. Не могли бы вы поделиться им с нами? –

+0

@JB Nizet - Конечно. Мы говорим нашим пользователям: «Мы не используем файлы cookie, период». Наше приложение является конфиденциальным и может сказать, что это хорошо. Теперь сеансовые файлы cookie, конечно, отличаются от более долгоживущих, но это различие потеряно для многих пользователей. На самом деле это касается ВОСПРОИЗВЕДЕНИЯ конфиденциальности. В любом случае, это означает, что мне нужно продолжать сеанс через URL-адрес (со всеми ВИДАМИ гарантий от угона, obv). Но формат «path-parameter» смущает некоторые браузеры, когда дело доходит до обслуживания контента, который пользователи могут сохранить (некоторые браузеры используют jsessionid для частичного имени файла). –

+0

@Will Hartung - Очень полезно, спасибо. И да, вы правы, что мы должны быть осторожны в анализе параметров из запроса, который на раннем этапе его жизненного цикла. По этой причине я бы не использовал 'getParameter()'; Я просто разбираю его из строки запроса. (Который, как вы также указываете, означает, что мой параметр id сеанса не может быть POSTED, но все в порядке, поскольку URL-адреса POST все еще могут содержать строки запросов.) –

ответ

1

Самый простой способ - построить Tomcat из исходного кода и взломать класс CoyoteAdapter.java.

Здесь находится этот код, но он не является легко расширяемой частью кода, где вы можете просто подключить немного кода для перехвата этой части конвейера запроса.

Вы можете получить умный и реализовать свой собственный Connector, который полагается на ваш собственный CoyoteAdapter, а не просто взломать его «на месте», но в итоге у вас все еще будет проблема обслуживания, связанная с поддержанием обновлений и т. Д.

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

Это важно, потому что, хотя для GETs синтаксический анализ параметра выполняется из заголовка запроса, для POST он основан на содержимом. И если вы спросите запрос о параметре, все равно, будет ли он POST или GET, и будет «делать правильную вещь» автоматически.

Это означает, что если вы запрашиваете параметр запроса из POST, конвейер будет потреблять входной поток (который начинает указывать на полезную нагрузку запроса после заголовков) до кода приложения пользователя. В зависимости от варианта использования, но некоторым приложениям нужен необработанный поток, поэтому вам нужно быть осторожным, используя встроенную логику параметров запроса, вместо того, чтобы воздействовать на исходный URL-адрес.

Вы также можете уйти от этого с помощью простого фильтра, а затем вы можете применить HttpServletRequest к базовой реализации Tomcat (имя кого-то меня сейчас не устраивает), а затем вызвать код setSessionID на что. Dunno, если это слишком поздно в цикле обработки или нет, вполне может быть.

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

Смежные вопросы