Re: [PATCH 51489] ProxyPassReverse issue + patch
Hi Jim, Am 10.07.2011 16:57, schrieb Jim Jagielski: Try: Proxy balancer://196f045aca6adc82a0b6eea93ed286a1/ 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: Proxy balancer://196f045aca6adc82a0b6eea93ed286a1 BalancerMember http://server-1.local status=-SE BalancerMember http://server-2.local status=-SE /Proxy 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=revisionrevision=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 VirtualHost section is:
VirtualHost _default_:443
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]
Directory /
Options Includes Multiviews FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
/Directory
Directory /opt/httpd2/htdocs/ssldocs/
AuthType SECURE_USER
require valid-user
Satisfy Any
/Directory
IfModule mod_authz_host.c
Directory /
Options + Indexes +Multiviews
AuthType SECURE_USER
require valid-user
satisfy Any
/Directory
Location /ATS/
AuthType SECURE_USER
require valid-user
ProxyPass http://192.2.0.25:8080/ATSAdmin
ProxyPassReverse http://192.2.0.25:8080/ATSAdmin
satisfy Any
/Location
/IfModule
/VirtualHost
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://IP_Address/App1 showing my own authorization.
When I will enter https://ip_address/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:
Location /wbm1
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
/Location
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=revisionrevision=1143225 http://svn.apache.org/viewvc?view=revisionrevision=1143222 http://svn.apache.org/viewvc?view=revisionrevision=1143221 http://svn.apache.org/viewvc?view=revisionrevision=1141203 http://svn.apache.org/viewvc?view=revisionrevision=1141201 http://svn.apache.org/viewvc?view=revisionrevision=1140075 http://svn.apache.org/viewvc?view=revisionrevision=1140069 http://svn.apache.org/viewvc?view=revisionrevision=1130186 http://svn.apache.org/viewvc?view=revisionrevision=1131393 http://svn.apache.org/viewvc?view=revisionrevision=1129956 http://svn.apache.org/viewvc?view=revisionrevision=1129891 http://svn.apache.org/viewvc?view=revisionrevision=1129886 http://svn.apache.org/viewvc?view=revisionrevision=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=revisionrevision=1143225 http://svn.apache.org/viewvc?view=revisionrevision=1143222 http://svn.apache.org/viewvc?view=revisionrevision=1143221 http://svn.apache.org/viewvc?view=revisionrevision=1141203 http://svn.apache.org/viewvc?view=revisionrevision=1141201 http://svn.apache.org/viewvc?view=revisionrevision=1140075 http://svn.apache.org/viewvc?view=revisionrevision=1140069 http://svn.apache.org/viewvc?view=revisionrevision=1130186 http://svn.apache.org/viewvc?view=revisionrevision=1131393 http://svn.apache.org/viewvc?view=revisionrevision=1129956 http://svn.apache.org/viewvc?view=revisionrevision=1129891 http://svn.apache.org/viewvc?view=revisionrevision=1129886 http://svn.apache.org/viewvc?view=revisionrevision=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.
