[PATCH] Reverse proxy and authentication

[Graham Leggett <gr...@dsn.ericsson.se>]

Hi all,

This is the patch that fixes authetication when used with a reverse
proxy.

Currently if an attempt is made using a <Location> structure to password
protect a URL that has been reverse proxied, Apache sends a
"Proxy-authenticate" header instead of an "WWW-authenticate" header.
This confuses the browser, which thinks the Apache webserver is a
website and not a proxy, and the authentication fails.

In the code currently a variable request_rec->proxyreq is set non-zero
if the request is a proxy request. This patch extends that variable to
three states, NONE, PROXY and REVERSE with the values 0, 1 and 2
respectively. This is backward compatible with the "non-zero" behaviour,
and allows the authenticate code to distinguish between the requests.

This patch does not yet fix the case where a website is reverse proxied
through another proxy, still working on it.

The src/CHANGES file:

  *) Fixed proxy/www authentication mixup when authenticating reverse
proxied
     URLs. [Graham Leggett <mi...@sharp.fm>]

No PR's outstanding.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight...

Re: [PATCH] Reverse proxy and authentication

[Graham Leggett <mi...@sharp.fm>]

Dean Gaudet wrote:

> [Hey Graham, it's more convenient if you send one attachment with the
> whole patch rather than an individual attachments each with one-file
> attachments, thanks.]

Sorry about that - I created a single file patch, then tried to test it
and it wouldn't work. Turned out to be a problem with Solaris patch...

> As Roy might say, "there is no such thing as a reverse proxy".  He's
> referring to the fact that if you read the rfc you won't find mention of a
> "reverse proxy", only of a proxy.  And strictly speaking, a proxy requires
> absolute URIs, for example, so this application is definately not an
> *http* proxy.  The core's concept of proxy is closer to that of an http
> proxy...

Reverse proxy isn't mentioned in any proxy rfc because on the frontend a
reverse proxy as actually a normal website. There is no way the browser
can tell that the URL it tried to fetch is proxied in any way, only the
laws of HTTP apply here.

This is where the problem lies. When authentication is added to a
reverse proxied URL using the <Location> braces, mod_proxy starts
talking proxy-speak, because proxy-speak is the only language it has
been programmed to speak. The browser receives "Proxy-Authentication:",
but because the browser is speaking HTTP to the website, and not Proxy,
it disregards the response as an error, and authentication doesn't work.

> The problem I see here is that really what the proxy module is being used
> as here is as a special purpose database for fetching response objects.

This is exactly how it's behaving, yes.

> Why does it set proxyreq = 1?  If there were a module which was fetching
> objects from a db and caching them locally we wouldn't be setting proxyreq
> = 1 for that module... how is this "reverse proxy" different?

I don't know - I don't fully understand how the rest of Apache responds
to proxy requests, and my approach was to keep the behavior the same as
it was, just change the authentication.

Basically Apache seems to be using the proxyreq variable to answer the
question "Is this request a proxy request?". Trouble is, it's too vague
a question, because in reality a proxy request can take two forms:

Proxy frontend <--> Proxy backend (normal proxy)
HTTP frontend <--> Proxy backend (reverse proxy)

What the patch tries to do is turn this two-state variable (proxy/no
proxy) into a three state variable (reverse/normal/none) in a way that's
backward compatible with the rest of the code. Ideally there should be a
simple way of determining whether the frontend is Proxy or HTTP so that
we can speak the correct language to the browser when it submits a
request.

Is there a better way of doing this?

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight...

Re: [PATCH] Reverse proxy and authentication

[Graham Leggett <mi...@sharp.fm>]

[I'm sending this message again because I didn't see it come through the
list...]

Dean Gaudet wrote:

> [Hey Graham, it's more convenient if you send one attachment with the
> whole patch rather than an individual attachments each with one-file
> attachments, thanks.]

Sorry about that - I created a single file patch, then tried to test it
and it wouldn't work. Turned out to be a problem with Solaris patch...

> As Roy might say, "there is no such thing as a reverse proxy".  He's
> referring to the fact that if you read the rfc you won't find mention of a
> "reverse proxy", only of a proxy.  And strictly speaking, a proxy requires
> absolute URIs, for example, so this application is definately not an
> *http* proxy.  The core's concept of proxy is closer to that of an http
> proxy...

Reverse proxy isn't mentioned in any proxy rfc because on the frontend a
reverse proxy as actually a normal website. There is no way the browser
can tell that the URL it tried to fetch is proxied in any way, only the
laws of HTTP apply here.

This is where the problem lies. When authentication is added to a
reverse proxied URL using the <Location> braces, mod_proxy starts
talking proxy-speak, because proxy-speak is the only language it has
been programmed to speak. The browser receives "Proxy-Authentication:",
but because the browser is speaking HTTP to the website, and not Proxy,
it disregards the response as an error, and authentication doesn't work.

> The problem I see here is that really what the proxy module is being used
> as here is as a special purpose database for fetching response objects.

This is exactly how it's behaving, yes.

> Why does it set proxyreq = 1?  If there were a module which was fetching
> objects from a db and caching them locally we wouldn't be setting proxyreq
> = 1 for that module... how is this "reverse proxy" different?

I don't know - I don't fully understand how the rest of Apache responds
to proxy requests, and my approach was to keep the behavior the same as
it was, just change the authentication.

Basically Apache seems to be using the proxyreq variable to answer the
question "Is this request a proxy request?". Trouble is, it's too vague
a question, because in reality a proxy request can take two forms:

Proxy frontend <--> Proxy backend (normal proxy)
HTTP frontend <--> Proxy backend (reverse proxy)

What the patch tries to do is turn this two-state variable (proxy/no
proxy) into a three state variable (reverse/normal/none) in a way that's
backward compatible with the rest of the code. Ideally there should be a
simple way of determining whether the frontend is Proxy or HTTP so that
we can speak the correct language to the browser when it submits a
request.

Is there a better way of doing this?

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight...

Re: [PATCH] Reverse proxy and authentication

[Doug MacEachern <do...@cp.net>]

On Sun, 16 May 1999, Dean Gaudet wrote:

> p.s. I think the problem is that r->proxyreq is overloaded -- it's being
> used as both a note to the core that the request is being handled by an
> HTTP/1.0 proxy, *and* being used as a note from mod_proxy to itself that
> it is in fact handling the request.  The second can be solved some other
> way -- no other module gets its own private field in request_rec. 

well, mod_perl uses it too, proxy modules written in Perl can decide
to handle a proxy request if $r->proxyreq() returns true.

-Doug

Re: [PATCH] Reverse proxy and authentication

[Dean Gaudet <dg...@arctic.org>]

p.s. I think the problem is that r->proxyreq is overloaded -- it's being
used as both a note to the core that the request is being handled by an
HTTP/1.0 proxy, *and* being used as a note from mod_proxy to itself that
it is in fact handling the request.  The second can be solved some other
way -- no other module gets its own private field in request_rec. 

Dean

Re: [PATCH] Reverse proxy and authentication

[Dean Gaudet <dg...@arctic.org>]

[Hey Graham, it's more convenient if you send one attachment with the
whole patch rather than an individual attachments each with one-file
attachments, thanks.]

As Roy might say, "there is no such thing as a reverse proxy".  He's
referring to the fact that if you read the rfc you won't find mention of a
"reverse proxy", only of a proxy.  And strictly speaking, a proxy requires
absolute URIs, for example, so this application is definately not an
*http* proxy.  The core's concept of proxy is closer to that of an http
proxy...

The problem I see here is that really what the proxy module is being used
as here is as a special purpose database for fetching response objects. 
Why does it set proxyreq = 1?  If there were a module which was fetching
objects from a db and caching them locally we wouldn't be setting proxyreq
= 1 for that module... how is this "reverse proxy" different? 

Dean