Bug 462598

Summary: SEP will show raw text when there is a jsessionid attached to the url
Product: [Retired] JBoss Customer Support Portal Reporter: Frank Merenda <fmerenda>
Component: OtherAssignee: JBoss CSP Bug Watch List <csp-bugs-watch>
Status: CLOSED WONTFIX QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 1.4CC: jsanda, mamburn, tmirc
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-31 17:39:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Frank Merenda 2008-09-17 13:26:19 UTC
If you go to the login submit page directly *with* a jsessionid attached (you don't have to be logged in):

   https://support.redhat.com/support-portal/loginSubmit.html;jsessionid=2384028390480890498023

raw text will show up in your browser.

If you go to the support-portal main page, or the loginSubmit.html

   https://support.redhat.com/support-portal/

It doesn't happen.

Comment 1 Mike Amburn 2008-10-16 18:13:43 UTC
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?

Comment 2 Nathan Lugert 2009-02-18 12:24:33 UTC
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.

Comment 3 John Sanda 2009-03-11 17:10:08 UTC
I am able to reproduce this with the following URLs as welll:

https://support.redhat.com/support-portal/loginSubmit.html;foo https://support.redhat.com/support-portal/loginSubmit.html; 

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.

Comment 4 John Sanda 2009-03-17 15:04:20 UTC
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?

Comment 5 Mike Amburn 2009-03-19 01:38:29 UTC
John, this is not entirely true. I always have cookies enabled, and I've gotten the error many times. Others likewise.

Comment 6 John Sanda 2009-03-19 15:35:18 UTC
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.

Comment 7 Tom Mirc 2009-03-19 15:46:34 UTC
John,

So the issue has been resolved in stage by applying the rewrite rule to the JSP tags?

Comment 8 John Sanda 2009-03-19 16:23:35 UTC
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.

Comment 9 David Spalding 2011-01-31 17:39:00 UTC
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 
classification.

Comment 10 David Spalding 2011-01-31 17:47:11 UTC
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 
classification.