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.
