Re: [squid-users] url-rewrite & digest authentication not working together

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 15 Jul 2010 01:55:28 +0000

On Wed, 14 Jul 2010 12:07:45 -0700 (PDT), Mike Melson
<mike.melson_at_caringo.com> wrote:
> Hi -
>
> I'm having trouble using squid plus a url-rewrite-program as a reverse
> proxy to a system that requires digest authentication.
>
> Digest authentication fails because the uri=<string> in the
Authorization
> header isn't rewritten & so it doesn't match the POST URI created by
> url-rewrite-program. Is there a way to also rewrite the uri string in
the
> Authorization header before squid sends it to the originserver?

No. This is one of the limits of re-writing the requested URL while it is
in transit.

Consider what the reason for having that URI in the Authorization header
means:
  The client is passing specific credentials to a security zone identified
by the URI.
If the URI is being used even in part as realm then the encryption itself
is salted on the public URI.

>
> If it helps clarify, I'm using curl to POST to squid as a reverse proxy
to
> a custom web server. And, if I eliminate the url-rewrite-program
> authorization works fine.
>
> e.g. [curl] --> POST /myfile.txt --> [squid (url-rewrite myfile.txt to
> <32-bit hex string>)] --> POST /<32bit-hex-string> --> [originserver]

URL-re-writing is a rather nasty violation of HTTP. Where possible you
need to remove it.

Squid in reverse proxy mode acts exactly like a client web browser when
contacting the web server. Your web server should always be aware of it's
public URIs and able to handle requests for them.

Amos
Received on Thu Jul 15 2010 - 01:55:34 MDT

This archive was generated by hypermail 2.2.0 : Thu Jul 15 2010 - 12:00:04 MDT