mod_proxy_http and jetty
beall at usc.edu
Fri Sep 23 19:03:15 BST 2011
Thanks for the detailed explanation Peter.
I noticed some of the hints online about forwarding the user info via a separate header and then decoding it in the application. I was hoping to not have to do this.
You confirmed my suspicion that it was the HTTP proxy that was disallowing the transfer.
I've also run into the issues with the versioning issues as well as the eclipse plugin versus the maven plugin. I did manage to get it to run successfully with JAAS ldap authentication mirroring production with the http proxy. Remote_user would have been useful for local testing.
I'll have to try proxy_ajp with the latest Jetty download instead of the one in the maven plugin which is still stuck at 6.1.26.
On Sep 23, 2011, at 10:37 AM, Peter Schober wrote:
> * Russell Beall <beall at usc.edu> [2011-09-23 19:11]:
>> I am testing out the use of Jetty for shibboleth instead of Tomcat,
>> with Apache in front. I found that mod_proxy_ajp is prone to errors
>> (in jetty) and the jetty documentation strongly recommends the use
>> of HTTP proxy.
> If you're referring to the "Using AJP" on this page:
> it seems to me that every single of those 5 items given in that
> section (why not to use AJP) is now outdated or nonsensical, given the
> existance of mod_proxy_ajp.
> Note that I'm not saying Jetty works great with AJP, as I've never
> used Jetty (first struggled finding the right version to download --
> Codehaus vs. Mortbay vs. Eclipse, Hightide vs. non-H., Versions 6, 7
> or 8 -- and couldn't get myself to wade though the dozens of config
> files trying to figure this thing out.)
>> When switching to this mode I found that the REMOTE_USER information
>> is not transmitted in the proxy, even though it does get proxied if
>> AJP is used.
> What CGIs call REMOTE_USER is a data structure that's internal to
> Apache httpd ($r->user), which you cannot forward via HTTP (the same
> way you cannot "forward" httpd environment variables via HTTP).
> What you can do is stick it into any old HTTP request header of your
> choice, constrained by HTTP header name restrictions (e.g. you can't
> have REMOTE_USER, only X-REMOTE-USER, which is not the same, so you
> could as well call the header name X-A3C1D161437906E50BF77DB560709E54).
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users