Re: [PATCH 51489] ProxyPassReverse issue + patch
Hi Jim, Am 10.07.2011 16:57, schrieb Jim Jagielski: Try: Thank you for your hint. I tried that, but it doesn't change anything. :( Micha
Re: [PATCH 51489] ProxyPassReverse issue + patch
Hi Nick, On 9 Jul 2011, at 11:16, Nick Kew wrote: On 8 Jul 2011, at 17:29, Micha Lenk wrote: I'm using Apache as a reverse proxy in a simple load balancer setup. I use ProxyPassReverse in order to re-write the backend server name in HTTP redirections (ie. in the Location header of the HTTP response). My configuration for the virtual host essentially looks like this: BalancerMember http://server-1.local status=-SE BalancerMember http://server-2.local status=-SE Is the absence of slashes after local there intentional? You have a slash in your ProxyPass[Reverse] directives. Yes, the absence of slashes after local is intentional. If I added them, the double slash in the Location: header of a redirect response would indeed be gone, but it would in turn cause a double slash to be added to *every* backend request. In case of a thttpd as backend, this would cause the backend to refuse all requests entirely. :( This seems to be different issue, but maybe I should try to fix this instead... What I bother about is the additional slash before '/foo/', so I digged into the source code and found the following lines in modules/proxy/proxy_util.c: That's not easy to follow: your comments don't cross-reference to the code until I've opened a lot more windows than I have screen space for. A link to your bugzilla report would've helped, and your reference to source is ambiguous - I guessed /trunk/. Correct. When digging in source for this kind of thing, the "annotate" feature of svn is your best tool: http://svn.eu.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?annotate=1138627 The lines you're unhappy about were introduced in r771587: http://svn.eu.apache.org/viewvc?view=revision&revision=771587 which has quite an informative commit message. Maybe that might help to figure out the purpose? Thank you for the hints. I will take a closer look on the diff once time permits. I should have done that before... Cheers, Micha
Proxy authentication
Dear users, I have problems with proxy authorization and I could not image where is a problem. Configuration in my : SSLEngine on SSLProxyEngine on ProxyRequests off RewriteEngine on RewriteCond %{REQUEST_METHOD} ^TRACE RewriteMap pages txt:/opt/httpd2/conf/pages.txt RewriteRule ^/([^/]+)${pages:$1|/$1} $ RewriteRule ^/([^/]+)/(.*)${pages:$1|/opt/httpd2/htdocs/ssldocs/$1}/$2 [L] Options Includes Multiviews FollowSymLinks AllowOverride None Order deny,allow Deny from all AuthType SECURE_USER require valid-user Satisfy Any Options + Indexes +Multiviews AuthType SECURE_USER require valid-user satisfy Any AuthType SECURE_USER require valid-user ProxyPass http://192.2.0.25:8080/ATSAdmin ProxyPassReverse http://192.2.0.25:8080/ATSAdmin satisfy Any In the module is mentioned: r->ap_auth_type = SECURE_USER; Format of the file pages.txt is: App1 /opt/App1/htdocs App1 App2 /opt/App2/htdocs App2 App3 /opt/App3/htdocs App3 https:///ATS/ I want to authorized over my module and when the authorization is done the it is proxied to the http://192.2.0.25:8080/ATSAdmin. Could you please let me know where I have made a mistake? My module have following hooks: static void register_hooks(apr_pool_t *p) { ap_hook_post_config(init_Module,NULL,NULL,APR_HOOK_MIDDLE); ap_hook_auth_checker(auth_handler,NULL,NULL,APR_HOOK_MIDDLE); ap_hook_check_user_id(access_handler,NULL,NULL,APR_HOOK_MIDDLE); ap_hook_handler(notification_handler,NULL,NULL,APR_HOOK_MIDDLE); ap_hook_fixups(fixups,NULL,NULL,APR_HOOK_MIDDLE); ap_hook_child_init(init_Child,NULL,NULL,APR_HOOK_MIDDLE); ap_hook_handler(secure_handler,NULL,NULL,APR_HOOK_MIDDLE); ap_hook_handler(login_handler,NULL,NULL,APR_HOOK_MIDDLE); ap_hook_handler(single_login_handler,NULL,NULL,APR_HOOK_MIDDLE); ap_hook_handler(logout_handler,NULL,NULL,APR_HOOK_MIDDLE); } When the access_checker return value is OK than it shown me page 404. When the access_checker return value is DECLINED that it shown me page unauthorized access. Shal I use some http redirection to the proxy pages? When I will do that so that configuration is: ProxyPass http://192.2.0.25/ Order deny,allow Allow from all AuthType Basic AuthName "Password Required" AuthUserFile password.file AuthGroupFile group.file Require group usergroup Than all works fine. -- Best Regards / S pozdravem Petr Hracek
Re: [vote] mod_ldap
On Monday 11 July 2011, William A. Rowe Jr. wrote: > On 7/10/2011 5:34 PM, Roy T. Fielding wrote: > > Regardless of anyone else's opinion, the addition or deletion of > > a new API to our product is a technical change that can be > > vetoed. Likewise, the API being an incomplete abstraction that > > isn't needed in httpd is a valid technical reason to veto it > > even if it had once been in apr-util. > > > > Other than the convoluted history of this particular argument, > > I don't see any reason for further frustration. Revert the > > commit. > > I believe svn rm ... svn cp -r of the origin files to jump across > the rejected patches is the most efficient and least confusing > revert? Because of the other changes that we want to preserver, I think doing one big revert commit may be easier. > The only complexity is to ensure configure.in/ or other peripheral > changes are not lost. I have the cycles do this Tuesday, if not > Monday. With a bit of git-foo, I have produced this: http://people.apache.org/~sf/revert_ldap.diff Which should be the combined revert of http://svn.apache.org/viewvc?view=revision&revision=1143225 http://svn.apache.org/viewvc?view=revision&revision=1143222 http://svn.apache.org/viewvc?view=revision&revision=1143221 http://svn.apache.org/viewvc?view=revision&revision=1141203 http://svn.apache.org/viewvc?view=revision&revision=1141201 http://svn.apache.org/viewvc?view=revision&revision=1140075 http://svn.apache.org/viewvc?view=revision&revision=1140069 http://svn.apache.org/viewvc?view=revision&revision=1130186 http://svn.apache.org/viewvc?view=revision&revision=1131393 http://svn.apache.org/viewvc?view=revision&revision=1129956 http://svn.apache.org/viewvc?view=revision&revision=1129891 http://svn.apache.org/viewvc?view=revision&revision=1129886 http://svn.apache.org/viewvc?view=revision&revision=1129808 It builds for me with apr 1.x, but I haven't done any other checks or review. But maybe it is something you can build on. Especially r1142938 needs checking, I think I may have accidentally reverted some bits from that when resolving some conflicts. The concatenated original commits are at: http://people.apache.org/~sf/reverted_ldap_commits.txt And the separate reverts: http://people.apache.org/~sf/ldap_revert_commtis.txt
Re: [vote] mod_ldap
On 12.07.2011 00:35, Stefan Fritsch wrote: > On Monday 11 July 2011, William A. Rowe Jr. wrote: >> On 7/10/2011 5:34 PM, Roy T. Fielding wrote: > Especially r1142938 needs checking, I think I may have accidentally > reverted some bits from that when resolving some conflicts. I can check and reapply where ncessary after the ldap revert. No problem. Regards, Rainer
Re: [vote] mod_ldap
On 7/11/2011 5:35 PM, Stefan Fritsch wrote: > On Monday 11 July 2011, William A. Rowe Jr. wrote: >> On 7/10/2011 5:34 PM, Roy T. Fielding wrote: >>> Regardless of anyone else's opinion, the addition or deletion of >>> a new API to our product is a technical change that can be >>> vetoed. Likewise, the API being an incomplete abstraction that >>> isn't needed in httpd is a valid technical reason to veto it >>> even if it had once been in apr-util. >>> >>> Other than the convoluted history of this particular argument, >>> I don't see any reason for further frustration. Revert the >>> commit. >> >> I believe svn rm ... svn cp -r of the origin files to jump across >> the rejected patches is the most efficient and least confusing >> revert? > > Because of the other changes that we want to preserver, I think doing > one big revert commit may be easier. I will sandbox the state of trunk before committing, the files can always be svn cp'ed from sandbox to trunk when and if agreed upon. >> The only complexity is to ensure configure.in/ or other peripheral >> changes are not lost. I have the cycles do this Tuesday, if not >> Monday. > > With a bit of git-foo, I have produced this: > > http://people.apache.org/~sf/revert_ldap.diff > > Which should be the combined revert of > > http://svn.apache.org/viewvc?view=revision&revision=1143225 > http://svn.apache.org/viewvc?view=revision&revision=1143222 > http://svn.apache.org/viewvc?view=revision&revision=1143221 > http://svn.apache.org/viewvc?view=revision&revision=1141203 > http://svn.apache.org/viewvc?view=revision&revision=1141201 > http://svn.apache.org/viewvc?view=revision&revision=1140075 > http://svn.apache.org/viewvc?view=revision&revision=1140069 > http://svn.apache.org/viewvc?view=revision&revision=1130186 > http://svn.apache.org/viewvc?view=revision&revision=1131393 > http://svn.apache.org/viewvc?view=revision&revision=1129956 > http://svn.apache.org/viewvc?view=revision&revision=1129891 > http://svn.apache.org/viewvc?view=revision&revision=1129886 > http://svn.apache.org/viewvc?view=revision&revision=1129808 Sorry, I don't see applying a mega-revert. Either piecemeal or wholesale svn cp's from pre-1129808 seems more sensible. The later is more legible in svn, because re-applying the commits with proper attribution would be messy.