You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Jairo Jimenez <ja...@gmail.com> on 2020/03/24 13:19:08 UTC
[users@httpd] Reverse proxy
Greetings I am new to apache. so please dont be so hard if this is too basic
I;ve been practicing by my self looking for scenarios to solve, but I have
this a particular one that I can[t figure out.
I manage to set some sore of reverse proxy to forward a website that I have
on an intranet.(forward it to external net throug VPN).
The thing I cant figure out is that when I acces this site through the
proxy, it prompts to enter the user name an pass but it is doing this for
every resource that needs to download, eg: images, style sheets,scripts
every thing.
Is there a way I can configure apache confs to manage this and store some
kind of cookie or cache to avoid this and enter login credentials just
once.?
Re: [users@httpd] Reverse proxy
Posted by Jairo Jimenez <ja...@gmail.com>.
I just read some thread in serverfault where a user explain the same
situation I have and one comment suggest that the problem was resolve by *by
loading module LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
instead of LoadModule mpm_worker_module modules/mod_mpm_worker.so* does
this sound believable to you? I understand that changing mpms in this
version of apache is not so easy(it has to be re build) so I want to ask
you first before I jump into such quest of rebuilding apache.
On Wed, Mar 25, 2020 at 9:39 AM Jairo Jimenez <ja...@gmail.com>
wrote:
> Thank you guys for such a quick response and elaborated answers. I haved
> turned on the browser's debug tool and what i can get from there is
> "Status": 401 unauthorized for many resources.
> As per setting cookies I havent try any of this, dont know how to at the
> moment. here is the configuration I have in my vhost file:
>
> ProxyRequests Off
> ProxyPreserveHost Off
>
> <Proxy *>
> Order deny,allow
> Allow from all
> </Proxy>
>
> ProxyPass /innerLink/ http://intrasrv01:8080/sites/Home.aspx
> ProxyPassReverse /innerLink/ http://intrasrv01:8080/sites/Home.aspx
>
> ProxyPass / http://intrasrv01:8080/
> ProxyPassReverse / http://intrasrv01:8080/
>
> RequestHeader unset Accept-Encoding
> AddOutputFilterByType SUBSTITUTE text/html
> Substitute "s|http://intrasrv01:8080/|http://172.16.27.7:8080/|ni"
>
> the site is in a sharepoint 2010 server. The new odd thing is happening is that sometimes loads almost all resources with just one login, and some times is prompting for ever
>
>
> On Tue, Mar 24, 2020 at 8:28 PM Muggeridge, Matt <ma...@hpe.com>
> wrote:
>
>> I’ll add a little more about cookies to Mark’s excellent answer…
>>
>>
>>
>> If you’re using cookies for passing authentication tokens via the
>> reverse-proxy, then read about ProxyPassReverseCookiePath.
>>
>>
>>
>> E.g. let’s say your proxy uses the path “/foo/” and this is mapped to ”/” on
>> the backend. Then you need a line in your configuration file:
>>
>>
>>
>> ProxyPassReverseCookiePath / /foo/
>>
>>
>>
>> COOKIES and REVERSE PROXY:
>>
>> - Client issues a login request.
>>
>> - The backend server responds to the login request with a "Set-Cookie"
>> header containing the cookie value and "path=/".
>>
>> - The reverse proxy must map the path to match the request, so "path=/"
>> must be rewritten as "path=/<proxy-request-path>/".
>>
>>
>>
>> NOTE: You can see what’s needed by tracing the Cookie content on the
>> backend server as well as this proxy. E.g. tracing the Set-Cookie in the
>> Proxy might require something like:
>>
>>
>>
>> LogFormat "%h %l %u %t \"%r\" \"%{Content-Type}o\" \"C:%{Cookie}i\"
>> \"S-C:%{Set-Cookie}o\" %>s %b"
>>
>> TransferLog "/store/log/httpd_access_log"
>>
>>
>>
>> Matt.
>>
>>
>>
>>
>>
>> *From:* Mark Brodis <ma...@colorado4x4.net>
>> *Sent:* Wednesday, 25 March 2020 1:58 AM
>> *To:* users@httpd.apache.org
>> *Subject:* Re: [users@httpd] Reverse proxy
>>
>>
>>
>> Without knowing exactly how your setup is configured, my guess is the
>> issue is that when you authenticate the first time to the remote site
>> whatever auth logic it's using that is not being persistent for your
>> connection or repeat requests. Typically this would be a cookie, you
>> authenticate successfully, the site gives you a cookie with some session ID
>> in it, with each request you send that cookie and it references a valid
>> session so it does not make you re-authenticate. That cookie from the site
>> could be set with specific parameters, what hosts or domains are valid for
>> it (when should the browser send this cookie with requests to those
>> hosts/domains), what it can be used for (HTTPonly is common), expiration
>> date, whether the browser should only send the cookie for secure
>> connections, etc.
>>
>>
>>
>> My guess is whatever that logic is, it's not getting back to the browser
>> so the browser either doesn't have, or isn't sending, whatever the site
>> wants to see to show that you already have a valid session.
>>
>>
>>
>> Commonly this could happen if you are accessing a site by a different
>> name, if you access 'coolsite.example.com' and that hits your proxy,
>> ends up fetching content from 'othersite.foo.org', then whatever cookies
>> the 'othersite.foo.org' site puts in the response, they should make it
>> back to the originating browser (will be in the response header), but they
>> will be for 'othersite.foo.org' and your browser will reject them
>> because they will come in a reponse to a request for '
>> coolsite.example.com', if your browser did save them it still wouldn't
>> use them for the next request because the name on them would be for '
>> othersite.foo.org' so it would dutifully only send those cookies to
>> requests to that site (which you wouldn't be doing, you'd be going to '
>> coolsite.example.com').
>>
>>
>>
>> If you turn on debugging (all modern browsers have this) or use a HTTP
>> capture local proxy (if running Windows then Fiddler Tool is very good) you
>> can see these transactions happen and see exactly what was sent and
>> received from the browser's perspective.
>>
>>
>>
>> That's how I would start debugging at least.
>>
>>
>>
>> If that is the problem..then how to fix that (which is pseudo faking out
>> the browser) would be to rewrite/modify the 'set-cookie' command as it
>> comes from the remote server in the response and change the host/domain
>> value in it to match what you actually went to. I believe that can be done
>> as part of mod_rewrite but I don't have a lot of experience doing that.
>>
>>
>>
>> Good luck.
>>
>>
>>
>> On Tue, Mar 24, 2020 at 7:19 AM Jairo Jimenez <ja...@gmail.com>
>> wrote:
>>
>> Greetings I am new to apache. so please dont be so hard if this is too
>> basic
>>
>>
>>
>> I;ve been practicing by my self looking for scenarios to solve, but I
>> have this a particular one that I can[t figure out.
>>
>>
>>
>> I manage to set some sore of reverse proxy to forward a website that I
>> have on an intranet.(forward it to external net throug VPN).
>>
>>
>>
>> The thing I cant figure out is that when I acces this site through the
>> proxy, it prompts to enter the user name an pass but it is doing this for
>> every resource that needs to download, eg: images, style sheets,scripts
>> every thing.
>>
>>
>>
>> Is there a way I can configure apache confs to manage this and store some
>> kind of cookie or cache to avoid this and enter login credentials just
>> once.?
>>
>>
Re: [users@httpd] Reverse proxy
Posted by Jairo Jimenez <ja...@gmail.com>.
Thank you guys for such a quick response and elaborated answers. I haved
turned on the browser's debug tool and what i can get from there is
"Status": 401 unauthorized for many resources.
As per setting cookies I havent try any of this, dont know how to at the
moment. here is the configuration I have in my vhost file:
ProxyRequests Off
ProxyPreserveHost Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /innerLink/ http://intrasrv01:8080/sites/Home.aspx
ProxyPassReverse /innerLink/ http://intrasrv01:8080/sites/Home.aspx
ProxyPass / http://intrasrv01:8080/
ProxyPassReverse / http://intrasrv01:8080/
RequestHeader unset Accept-Encoding
AddOutputFilterByType SUBSTITUTE text/html
Substitute "s|http://intrasrv01:8080/|http://172.16.27.7:8080/|ni"
the site is in a sharepoint 2010 server. The new odd thing is
happening is that sometimes loads almost all resources with just one
login, and some times is prompting for ever
On Tue, Mar 24, 2020 at 8:28 PM Muggeridge, Matt <ma...@hpe.com>
wrote:
> I’ll add a little more about cookies to Mark’s excellent answer…
>
>
>
> If you’re using cookies for passing authentication tokens via the
> reverse-proxy, then read about ProxyPassReverseCookiePath.
>
>
>
> E.g. let’s say your proxy uses the path “/foo/” and this is mapped to ”/” on
> the backend. Then you need a line in your configuration file:
>
>
>
> ProxyPassReverseCookiePath / /foo/
>
>
>
> COOKIES and REVERSE PROXY:
>
> - Client issues a login request.
>
> - The backend server responds to the login request with a "Set-Cookie"
> header containing the cookie value and "path=/".
>
> - The reverse proxy must map the path to match the request, so "path=/"
> must be rewritten as "path=/<proxy-request-path>/".
>
>
>
> NOTE: You can see what’s needed by tracing the Cookie content on the
> backend server as well as this proxy. E.g. tracing the Set-Cookie in the
> Proxy might require something like:
>
>
>
> LogFormat "%h %l %u %t \"%r\" \"%{Content-Type}o\" \"C:%{Cookie}i\"
> \"S-C:%{Set-Cookie}o\" %>s %b"
>
> TransferLog "/store/log/httpd_access_log"
>
>
>
> Matt.
>
>
>
>
>
> *From:* Mark Brodis <ma...@colorado4x4.net>
> *Sent:* Wednesday, 25 March 2020 1:58 AM
> *To:* users@httpd.apache.org
> *Subject:* Re: [users@httpd] Reverse proxy
>
>
>
> Without knowing exactly how your setup is configured, my guess is the
> issue is that when you authenticate the first time to the remote site
> whatever auth logic it's using that is not being persistent for your
> connection or repeat requests. Typically this would be a cookie, you
> authenticate successfully, the site gives you a cookie with some session ID
> in it, with each request you send that cookie and it references a valid
> session so it does not make you re-authenticate. That cookie from the site
> could be set with specific parameters, what hosts or domains are valid for
> it (when should the browser send this cookie with requests to those
> hosts/domains), what it can be used for (HTTPonly is common), expiration
> date, whether the browser should only send the cookie for secure
> connections, etc.
>
>
>
> My guess is whatever that logic is, it's not getting back to the browser
> so the browser either doesn't have, or isn't sending, whatever the site
> wants to see to show that you already have a valid session.
>
>
>
> Commonly this could happen if you are accessing a site by a different
> name, if you access 'coolsite.example.com' and that hits your proxy, ends
> up fetching content from 'othersite.foo.org', then whatever cookies the '
> othersite.foo.org' site puts in the response, they should make it back to
> the originating browser (will be in the response header), but they will be
> for 'othersite.foo.org' and your browser will reject them because they
> will come in a reponse to a request for 'coolsite.example.com', if your
> browser did save them it still wouldn't use them for the next request
> because the name on them would be for 'othersite.foo.org' so it would
> dutifully only send those cookies to requests to that site (which you
> wouldn't be doing, you'd be going to 'coolsite.example.com').
>
>
>
> If you turn on debugging (all modern browsers have this) or use a HTTP
> capture local proxy (if running Windows then Fiddler Tool is very good) you
> can see these transactions happen and see exactly what was sent and
> received from the browser's perspective.
>
>
>
> That's how I would start debugging at least.
>
>
>
> If that is the problem..then how to fix that (which is pseudo faking out
> the browser) would be to rewrite/modify the 'set-cookie' command as it
> comes from the remote server in the response and change the host/domain
> value in it to match what you actually went to. I believe that can be done
> as part of mod_rewrite but I don't have a lot of experience doing that.
>
>
>
> Good luck.
>
>
>
> On Tue, Mar 24, 2020 at 7:19 AM Jairo Jimenez <ja...@gmail.com>
> wrote:
>
> Greetings I am new to apache. so please dont be so hard if this is too
> basic
>
>
>
> I;ve been practicing by my self looking for scenarios to solve, but I have
> this a particular one that I can[t figure out.
>
>
>
> I manage to set some sore of reverse proxy to forward a website that I
> have on an intranet.(forward it to external net throug VPN).
>
>
>
> The thing I cant figure out is that when I acces this site through the
> proxy, it prompts to enter the user name an pass but it is doing this for
> every resource that needs to download, eg: images, style sheets,scripts
> every thing.
>
>
>
> Is there a way I can configure apache confs to manage this and store some
> kind of cookie or cache to avoid this and enter login credentials just
> once.?
>
>
RE: [users@httpd] Reverse proxy
Posted by "Muggeridge, Matt" <ma...@hpe.com>.
I’ll add a little more about cookies to Mark’s excellent answer…
If you’re using cookies for passing authentication tokens via the reverse-proxy, then read about ProxyPassReverseCookiePath.
E.g. let’s say your proxy uses the path “/foo/” and this is mapped to ”/” on the backend. Then you need a line in your configuration file:
ProxyPassReverseCookiePath / /foo/
COOKIES and REVERSE PROXY:
- Client issues a login request.
- The backend server responds to the login request with a "Set-Cookie" header containing the cookie value and "path=/".
- The reverse proxy must map the path to match the request, so "path=/" must be rewritten as "path=/<proxy-request-path>/".
NOTE: You can see what’s needed by tracing the Cookie content on the backend server as well as this proxy. E.g. tracing the Set-Cookie in the Proxy might require something like:
LogFormat "%h %l %u %t \"%r\" \"%{Content-Type}o\" \"C:%{Cookie}i\" \"S-C:%{Set-Cookie}o\" %>s %b"
TransferLog "/store/log/httpd_access_log"
Matt.
From: Mark Brodis <ma...@colorado4x4.net>
Sent: Wednesday, 25 March 2020 1:58 AM
To: users@httpd.apache.org
Subject: Re: [users@httpd] Reverse proxy
Without knowing exactly how your setup is configured, my guess is the issue is that when you authenticate the first time to the remote site whatever auth logic it's using that is not being persistent for your connection or repeat requests. Typically this would be a cookie, you authenticate successfully, the site gives you a cookie with some session ID in it, with each request you send that cookie and it references a valid session so it does not make you re-authenticate. That cookie from the site could be set with specific parameters, what hosts or domains are valid for it (when should the browser send this cookie with requests to those hosts/domains), what it can be used for (HTTPonly is common), expiration date, whether the browser should only send the cookie for secure connections, etc.
My guess is whatever that logic is, it's not getting back to the browser so the browser either doesn't have, or isn't sending, whatever the site wants to see to show that you already have a valid session.
Commonly this could happen if you are accessing a site by a different name, if you access 'coolsite.example.com<http://coolsite.example.com>' and that hits your proxy, ends up fetching content from 'othersite.foo.org<http://othersite.foo.org>', then whatever cookies the 'othersite.foo.org<http://othersite.foo.org>' site puts in the response, they should make it back to the originating browser (will be in the response header), but they will be for 'othersite.foo.org<http://othersite.foo.org>' and your browser will reject them because they will come in a reponse to a request for 'coolsite.example.com<http://coolsite.example.com>', if your browser did save them it still wouldn't use them for the next request because the name on them would be for 'othersite.foo.org<http://othersite.foo.org>' so it would dutifully only send those cookies to requests to that site (which you wouldn't be doing, you'd be going to 'coolsite.example.com<http://coolsite.example.com>').
If you turn on debugging (all modern browsers have this) or use a HTTP capture local proxy (if running Windows then Fiddler Tool is very good) you can see these transactions happen and see exactly what was sent and received from the browser's perspective.
That's how I would start debugging at least.
If that is the problem..then how to fix that (which is pseudo faking out the browser) would be to rewrite/modify the 'set-cookie' command as it comes from the remote server in the response and change the host/domain value in it to match what you actually went to. I believe that can be done as part of mod_rewrite but I don't have a lot of experience doing that.
Good luck.
On Tue, Mar 24, 2020 at 7:19 AM Jairo Jimenez <ja...@gmail.com>> wrote:
Greetings I am new to apache. so please dont be so hard if this is too basic
I;ve been practicing by my self looking for scenarios to solve, but I have this a particular one that I can[t figure out.
I manage to set some sore of reverse proxy to forward a website that I have on an intranet.(forward it to external net throug VPN).
The thing I cant figure out is that when I acces this site through the proxy, it prompts to enter the user name an pass but it is doing this for every resource that needs to download, eg: images, style sheets,scripts every thing.
Is there a way I can configure apache confs to manage this and store some kind of cookie or cache to avoid this and enter login credentials just once.?
Re: [users@httpd] Reverse proxy
Posted by Mark Brodis <ma...@colorado4x4.net>.
Without knowing exactly how your setup is configured, my guess is the issue
is that when you authenticate the first time to the remote site whatever
auth logic it's using that is not being persistent for your connection or
repeat requests. Typically this would be a cookie, you authenticate
successfully, the site gives you a cookie with some session ID in it, with
each request you send that cookie and it references a valid session so it
does not make you re-authenticate. That cookie from the site could be set
with specific parameters, what hosts or domains are valid for it (when
should the browser send this cookie with requests to those hosts/domains),
what it can be used for (HTTPonly is common), expiration date, whether the
browser should only send the cookie for secure connections, etc.
My guess is whatever that logic is, it's not getting back to the browser so
the browser either doesn't have, or isn't sending, whatever the site wants
to see to show that you already have a valid session.
Commonly this could happen if you are accessing a site by a different name,
if you access 'coolsite.example.com' and that hits your proxy, ends up
fetching content from 'othersite.foo.org', then whatever cookies the '
othersite.foo.org' site puts in the response, they should make it back to
the originating browser (will be in the response header), but they will be
for 'othersite.foo.org' and your browser will reject them because they will
come in a reponse to a request for 'coolsite.example.com', if your browser
did save them it still wouldn't use them for the next request because the
name on them would be for 'othersite.foo.org' so it would dutifully only
send those cookies to requests to that site (which you wouldn't be doing,
you'd be going to 'coolsite.example.com').
If you turn on debugging (all modern browsers have this) or use a HTTP
capture local proxy (if running Windows then Fiddler Tool is very good) you
can see these transactions happen and see exactly what was sent and
received from the browser's perspective.
That's how I would start debugging at least.
If that is the problem..then how to fix that (which is pseudo faking out
the browser) would be to rewrite/modify the 'set-cookie' command as it
comes from the remote server in the response and change the host/domain
value in it to match what you actually went to. I believe that can be done
as part of mod_rewrite but I don't have a lot of experience doing that.
Good luck.
On Tue, Mar 24, 2020 at 7:19 AM Jairo Jimenez <ja...@gmail.com>
wrote:
> Greetings I am new to apache. so please dont be so hard if this is too
> basic
>
> I;ve been practicing by my self looking for scenarios to solve, but I have
> this a particular one that I can[t figure out.
>
> I manage to set some sore of reverse proxy to forward a website that I
> have on an intranet.(forward it to external net throug VPN).
>
> The thing I cant figure out is that when I acces this site through the
> proxy, it prompts to enter the user name an pass but it is doing this for
> every resource that needs to download, eg: images, style sheets,scripts
> every thing.
>
> Is there a way I can configure apache confs to manage this and store some
> kind of cookie or cache to avoid this and enter login credentials just
> once.?
>