Bug 1419145

Summary: [GSS](6.4.z) Content type can show other header value after FORM auth restores request
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Aaron Ogburn <aogburn>
Component: WebAssignee: Jiri Ondrusek <jondruse>
Status: CLOSED CURRENTRELEASE QA Contact: Radim Hatlapatka <rhatlapa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.4.13CC: bmaxwell, csutherl, jondruse, mcada, rmaucher, rstancel
Target Milestone: CR1   
Target Release: EAP 6.4.16   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-06-22 09:24:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1434495, 1440846    
Attachments:
Description Flags
bz1419145repro.zip none

Description Aaron Ogburn 2017-02-03 17:06:17 UTC
Description of problem:

In particular scenarios, request.getContentType() incorrectly shows another header's value after FORM auth restores a request.

Version-Release number of selected component (if applicable):


How reproducible:

In specific scenario

Steps to Reproduce:
1. Deploy app with FORM auth (for example, the one attached)
2. Access app via ajp proxy.  Using httpd, it helps to reproduce the issue with the following in place to force a content type header in the requests:

RequestHeader set Content-Type application/x-www-form-urlencoded

3. Check the getContentType() return after following the redirect from j_security_check.  The example app will spit this out.

Actual results:

getContentType() may return incorrect value

Expected results:

getContentType() returns correct value

Additional info:

This can occur if the client provides a content type header in the request when following the j_security_check redirect.  It is also dependent upon coyote.Request.contentType() being called before the FormAuthenticator is reached.

This results in the issue in the following manner:

1) client performs form auth successfully and follows redirect after j_security_check with a request including a content-type header
2) coyote.Request.contentType() is called and stores a MessageBytes (contentTypeMB) for the content-type header
3) FormAuthenticator is reached and recycles the coyote.Request's mimeheaders. The coyote.Request is then still referring to a MessageBytes instance with contentTypeMB, although with a null value.
4) FormAuthenticator restores the request.  This can result in the contentTypeMB MessageBytes instance being reset with a new value.  Then subsequent calls to request.getContentType() may improperly return null or potentially the value from another header.

Note that AJP is more prone to this since it inherently calls Request.contentType() in its prepareRequest().  But it could be seen still on HTTP if something also results in an early Request.contentType() call prior to FormAuthenticator (for instance if the RequestDumperValve is enabled)

Comment 4 Aaron Ogburn 2017-02-06 14:32:21 UTC
Created attachment 1248046 [details]
bz1419145repro.zip

Comment 18 Michael Cada 2017-06-07 14:01:53 UTC
Verified with EAP 6.4.16.CP.CR1

Comment 19 Petr Penicka 2017-06-22 09:24:55 UTC
Released on June 20 2017 as part of the EAP 6.4.16 maintenance release.