On Tue, Aug 28, 2012 at 3:55 PM, Rainer Jung <rainer.j...@kippdata.de>wrote:
> Hi John, > > On 28.08.2012 01:25, Lowman, John Mr CTR USA AMC wrote: > >> I hope someone out there has some insight regarding the problem that >> I'm about to describe. All custom request header fields that are added via >> the SiteMinder policy server are being stripped (intentionally or >> accidentally) from the request header after passing through the Apache >> Tomcat "isapi_redirect.dll" ISAPI filter. >> > > Can you give an example of such a header, i.e. its name and a typical > value? > > You might want to check > > https://issues.apache.org/**bugzilla/show_bug.cgi?id=47679<https://issues.apache.org/bugzilla/show_bug.cgi?id=47679> > > though it should be fixed in 1.2.32. > > If you increase the redirector log level to debug, you will get additional > output of the form: > > Forwarding request header HEADER_NAME : HEADER_VALUE > > for each header. > > We have a website running on IIS and ColdFusion 10 that is protected >> using SiteMinder. When a web request comes in, SiteMinder intercepts the >> request and performs a HTTP 302 redirect to the policy servers for >> authentication. After successful authentication, the policy server adds >> some custom fields, such as "userid" and "mail", to the request header and >> fires it back to our web server. When using an ASP script below, I can see >> that these custom header fields appear in IIS, so I have proof that they >> are arriving intact in the header. However, the problem is that the custom >> request header fields get stripped out when viewing a ColdFusion page, >> which goes through the Apache Tomcat ISAPI filter. >> > > As Chris already asked: we need to understand the communication between > Client/Browser, SiteMinder and your IIS/Redirector > > Client -> IIS (HTTP Request) > > Now ?? SiteMinder ??? (what does intercept mean)? > Then ?? Fire Back ?? > > I suggest a quick check against the debug log first. > > Here is the "showheaders.asp" page that I used to view the custom >> header fields: >> >> --- BEGIN showheaders.asp --- >> > ... > > <% >> ' Iterate through the server variables collection and display >> each header along with its value >> for each header in Request.ServerVariables >> response.write header & " = " & Request.ServerVariables( >> **header) & " <br><br> " >> next >> %> >> > ... > > --- END showheaders.asp --- >> >> Here is the "showheaders.cfm" page that I used to view the custom header >> fields: >> >> --- BEGIN showheaders.cfm --- >> > ... > > <cfoutput>ALL_HTTP = #cgi.ALL_HTTP#</cfoutput> >> > > See below > > <cfdump var="#cgi#" label="cgi" expand="yes" /> >> <cfdump var="#getHTTPRequestData()#" /> >> > ... > > --- END showheaders.cfm --- >> >> The missing headers problem started after upgrading our server from >> ColdFusion MX 7 to ColdFusion 10. ColdFusion MX 7 ran on JRun; ColdFusion >> 10 runs on a modified version of Apache Tomcat. I suspect that the header >> fields are being stripped out by the ISAPI filter, because the custom >> fields are missing whether I use ColdFusion's built-in >> "getHTTPRequestData()" function, or from a Java equivalent on the >> ColdFusion page. >> >> --- BEGIN GetCredentialsFromHeader() --- >> > ... > > <cfset pageRequest = getPageContext().getRequest() /> >> <cfset pageRequestHeaderNames = pageRequest.getHeaderNames() /> >> <cfloop condition="#**pageRequestHeaderNames.** >> hasMoreElements()#"> >> <cfset thisName = pageRequestHeaderNames.**nextElement() >> /> >> <cfoutput> >> #thisName#='#pageRequest.**getHeader(thisName)#'<br >> /> >> </cfoutput> >> </cfloop> >> <cfdump var="#pageRequest#" label="Java Page Request" /> >> >> <!--- This is the ColdFusion way of getting request headers. ---> >> <cfdump var="#GetHTTPRequestData()#" label="HTTP Request >> Headers" /> >> >> <cfabort /> >> </cffunction> >> --- END GetCredentialsFromHeader() --- >> >> Another quirk that I noticed is that the "ALL_HTTP" CGI field exists >> after passing through the ISAPI filter, but it's blank. In contrast, the >> ALL_HTTP field is populated when viewing in IIS via the ASP script. >> > > Since CGI does more unwanted things to the HTTP headers (replacing > underscores with dashes, lowercasing names etc.) the ISAPI redirector uses > ALL_RAW. > > Now the specs: >> >> ColdFusion: version 10,282462 >> CF-Tomcat: N/A (It's integrated into >> ColdFusion 10) >> isapi_direct.dll: version 1.2.32.0 >> OS: Windows 2003 >> Java: JDK 1.6.0_33 >> VM Version: 20.8-b03 >> IIS: 6 >> >> I can't think of anything else at the moment. If anyone knows what's >> causing this, please help me. I'd be very grateful. >> > > Regards, > > Rainer > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@tomcat.**apache.org<users-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: users-h...@tomcat.apache.org > > John: Are you certain you are running the latest ISAPI redirector? ColdFusion 10, installed in standalone "server" mode uses a custom instance of Tomcat and ISAPI connector. This is a Adobe forked version. As a matter of fact, both, the connector and the Tomcat redirector side are different enough that the standard ISAPI re-director should not have worked. See explanation here: http://blogs.coldfusion.com/post.cfm/what-s-the-deal-with-tomcat-in-coldfusion-10 On the tech side, this is related to Adobe's choice to introduce a number of non-standard AJP data packages to the traffic between webserver and tomcat. Even within the standard AJP exchanges, there are modification to protocol data. Thus, if you use the out of the box installation of ColdFusion you are most likely not using ISAPI 1.2.32+. I am not certain why the Adobe supplied connector would strip any headers though; thus it still may be helpful to follow Rainer's advice above to dump headers to log file. As far as I understand you have three choices: a) Deploy a standard Tomcat instance, then deploy Coldfusion 10 as WAR app. In this scenario you can, then, introduce a connector of your choice. You have to check your application if it needs to be re-factored for different assumption on site-roots etc. b) If you can substantiate the claim with the evidence gathered (as you seem to be able to do), you can open a ticket with Adobe to fix their specific version of the connector. c) Go experimental: - Use an altertnate CFML engine that would be able to use the standard ISAPI connector: e.g. open source Railo CF Engine (getRailo.org) - Use an alternate connector: I am supporting the BonCode project that has support for CF 10 based interchanges (tomcatiis.riaforge.org) Cheers, B.
