Red Hat Bugzilla – Bug 462598
SEP will show raw text when there is a jsessionid attached to the url
Last modified: 2011-01-31 12:47:11 EST
If you go to the login submit page directly *with* a jsessionid attached (you don't have to be logged in):
raw text will show up in your browser.
If you go to the support-portal main page, or the loginSubmit.html
It doesn't happen.
This bug was reported in a previous version; moving from Struts2 to Struts was supposed to fix it. I'm guessing it did not, correct?
This bug only happens in production and cannot be duplicated in QA. I think it must have something to do with SSL or a redirect thing. Still investigating.
I am able to reproduce this with the following URLs as welll:
We do not run apache in our dev/QA environments, so I am wondering if it has anything to do with apache. I have submitted a ticket to see the proxy redirect rules. They may provide some additional insight and/or help me reproduce the issue.
I still have not found a solution to this, but there is a possible work around. The application server appends the jsessionid to the URL when the client does not have cookies enabled. It will first try to store the jsessionid in a cookie, and then resort to URL encoding if cookies are disabled. I believe this part of the Servlet spec. We could require users to enable cookies for this site. Doing so should altogether eliminate the problem. I understand that some users prefer to disable cookies due to security concerns, but since SEP is restricted to internal issues, I don't see why that would be an issue.
Tom, would this be an acceptable solution?
John, this is not entirely true. I always have cookies enabled, and I've gotten the error many times. Others likewise.
I did a bit more reading, and there may be some Struts 2 JSP tags that are doing the URL encoding to attach the jsessionid to the URL.
I had the following apache rewrite rule added in stage:
/support-portal/(.*);jsessionid=[0-9A-Z]*(.*) /support-portal/$1 [L]
This removes the jsessionid from the URL.
So the issue has been resolved in stage by applying the rewrite rule to the JSP tags?
No, not exactly. All HTTP requests are routed through an apache proxy layer before hitting the app server(s). The rewrite rule has been applied at the apache layer so that a request like https://support.stage.redhat.com/support-portal/login.html;jsessionid=34nl3nler8er8e would be changed to https://support.stage.redhat.com/support-portal/login.html.
I mentioned the Struts JSP tags because there may be some Struts code that is causing the jsessionid to be added to the URL.
As this is a low priority issue that does not effect external customers, I propose that we test the apache change instead of further pursuing application code changes.
Bugs are no longer tracked under this classification. CSP is now monitored in
Other | Customer Portal | Integrated app: JBoss CSP.
Please refile any current defect records or RFEs under the current