"Подставил" tomcat6 проигрышных сессий

Question

IWS - это настольное приложение с собственным компонентом webBrowser, которое при необходимости вызывает веб-приложение Scripting. Сценарии находятся в Tomcat6.

Сценарии - это в основном приложение JSP. (Действительно, это движок, который создает приложение JSP из действий человека через его графический интерфейс, такой как определение потоков, кнопок, контента и т. Д., Но я говорю о "скрипте", который он генерирует как JSP)

Мне нужно взломать сценарии, чтобы он мог разделить пространство (через фреймы) в этом компоненте webBrowser приложения IWS.

IWS вызывает 2 раза для запуска. Jsp:

• в первый раз, скрытым способом (вероятно, прямым http-запросом из кода IWS), без каких-либо специальных параметров. Первоначальный start.jsp делает 2 302 (таким образом, вызов посещает всего 3 страницы), он завершается использованием jsesionId как в cookie, так и в качестве параметра (но не в последних 302)

• во второй раз, с jSessionId и кучей важных параметров. Он использует только jSessionId в качестве параметра. Насколько я видел в fiddler, cookie не используется, когда он работает правильно, так как jsessionId находится внутри его собственного

Поэтому я думаю, что в первый раз это просто получить новый jSessionId.

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

Так что-то вроде:

• у нас был start.jsp... (на самом деле это называется что-то другое)

• и мы заканчиваем с:

  • start.app.jsp (оригинал start.jsp, только что переименованный)

  • start.jsp (новый html-файл, включающий предыдущий start.jsp)

Новый start.jsp использует свой собственный URL-адрес, изменяя start.jsp на start.app.jsp, чтобы вызвать настоящее приложение Scripting внутри iframe.

Но я страдаю от подобных сессионных проблем. Я не эксперт по коту. Я узнал, что он контролирует сессию с куки или с параметрами. Я думаю, что он настроен для работы с URL sessionId, но я не совсем уверен. Я установил META-INF/settings.xml, чтобы отключить использование файлов cookie в сеансах, но этот файл все еще отображается в списке файлов cookie.

Моя проблема заключается в том, что во второй раз вызывается start.jsp, кажется, что он чем-то похож на "старый cookie", игнорируя jsessionId из URL. Некоторые странные ошибки появляются в WWG00000E: WWGAIL - Ошибка: ID не был предоставлен для функции getInteractionKVPair Подробнее:

Это похоже на возвращение к старому куки с другим jsessionid. Этот "старый" jsessionid одинаков каждый раз, когда появляется ошибка.

Обнюхивая fiddler, я вижу, что второй файл start.jsp начинается с правильного jsessionId в URL-адресе, но его файлы cookie похожи на другой сеанс, и он останавливает добавление идентификатора jsession при каждом перенаправлении, поскольку это происходит. Это похоже на то, как это происходит в совершенно другой вселенной. Это нормально?????

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

Пожалуйста, у вас есть идеи?

Спасибо!

Отредактировано 2: если я поместил его без фреймов (восстановление по умолчанию start.jsp). На IWS работает только первый раз (взаимодействие), а в любом последующем проблема начинает появляться...

Answer 1

Хорошо, наконец-то решено...

По крайней мере, с этой версией Tomcat:

• Вызов jsp без jSessionId создает новый jSessionId в файле cookie вашего приложения.
• В дальнейшем любой html-запрос будет использовать cookie-файл jSessionId вместо того, который присутствует в URL-адресе, поэтому вы теряете любой тип поддержки мультисессии.

Это что-то особенное, чем в компоненте webBrowser, он выполняет двухэтапные соединения, первый запрос никогда не имеет связанного cookie, поэтому он работает нормально, давая вам cookie с новым jSessionId, а затем вы можете создать новый, без cookie, второй запрос, который использует jSessionId URL-адреса и не имеет файла cookie или файла cookie по умолчанию без jSessionId. Когда этот webBrowser запрашивает страницу jsp без jSessionId в своем URL-адресе, как уже было сказано, проблема начинается, поэтому, если первый запрос включает в себя вызов не jSessionIded, Tomcat выдает вам jSessionId, который установлен в вашем "файле cookie приложения по умолчанию", поэтому второй request игнорирует любой URL-адрес jSessionId, чтобы использовать тот, который указан в этом cookie.

В веб-браузере я заметил, что, по крайней мере, в Firefox очистка файлов cookie недостаточна для удаления этого файла "cookie по умолчанию". Но, возможно, это может быть классика: "Это занимает слишком много времени, поэтому вы думаете, что это чисто, но на самом деле это не так". Точно сказать не могу.

Я знаю, это звучит странно. У меня нет времени на дальнейшее тестирование по этому поводу.

Насколько я понял, это похоже на то, что когда он работает нормально, он работает как с "cookie-файлом сеанса" (без jSessionId), а когда он не работает, он берет "cookie-файл по умолчанию" (с jSessionId) и запускается игнорирование URL jSessionId.

Я отправил электронное письмо в список рассылки разработчиков Tomcat. (Один из них сказал, что правильным местом был список рассылки пользователя... но вот вы здесь;-))