Hi Amos,
Amos Jeffries a écrit :
This page is auth basic protected + ip based protected
http://proxy-03.love.mydomain.com/_admin/style.css
normally is should pass on the ip based auth basic auth scheme
But it fails.
it seems to be an X-Forwarded-For problem,
Depends on how your authentication helper is coded to check for IP and
whether you have X-Forwarded-For visible or silent in any given squid.
here is the apache peer access log
proxy-03.mydomain.com - - [18/Oct/2007:15:48:37 +0200] "GET
/_admin/style.css HTTP/1.0" 401 480 "-" "Mozilla/5.0 (Windows; U; W
indows NT 5.1; fr; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7"
and proxy squid access log:
Thu Oct 18 15:48:37 2007 4 12.34.56.78 TCP_REFRESH_MISS/401 855 GET
http://proxy-03.love.mydomain.com/_admin/style.css -
ROUNDROBIN_PARENT/php-04 text/html
we should have IP 12.34.56.78 instead of the proxy hostname
IP in stead of *which* peer hostname above?
"proxy-03.mydomain.com"? - apache configured with 'resolve hostnames on'
"proxy-03.love.mydomain.com"?
"php-04"? - squid configured with resolve hostnames on'
Sorry it's confusing.
In the apache log:
proxy-03.mydomain.com should have been 12.34.56.78
I use the proxy-03 hostname for both test on the content URL and the proxy name, which also work on my case.
I've identified a cache problem also. How a restricted content is cached or not by squid?
http://something.love.mydomain.com/_admin/style.css
here : "something" can be anything even "proxy-03"
the document is restricted.
php-04 in the name used in the squid config the peer originserver
resolved by squid by its /etc/hosts I suppose.
I've also tested without succes:
acl AuthPages urlpath_regex ^/(_admin|_rep2|_some3)
cache deny AuthPages
I was hopping squid to never cache the document and always request the
peer server passing auth challenge each time, seems no to work.
Sylvain.
