Henrik Nordstrom wrote:
From what I can tell the difference between the PASSTHRU and PASS is
only that PASSTHRU do not add any injected credentials from
external_acl, right?
Imho there is no need for more than two of these options.
I kind of agree. This is a step towards cleaning up the permutations a
bit. The old ones are not really pass-thru. As you note they all did
some synthesizing which can under some circumstances is mutually
exclusive with real pass-thru.
We temporarily have three:
PROXYPASS synthetic WWW-Auth
PASS synthetic Proxy-Auth
PASSTHRU semantic transparency
The fact that the first two were abusable as pass-thru and PASS in
particular in too many guides used as semantic transparent pass-thru is
a problem.
PASS -> WWW+Proxy authentication passed along as-is if present.
external_acl auth added as basic Proxy-Auth if none present.
Ideally yes. However the addition of Proxy-Auth from local environment
(without the option NOT to) breaks setups where side-band auth is done
and the real header auth needs to be fully semantically transparent.
(We just hit this case needing semantic transparent WWW-Auth pass-thru
which brought the confusion to light).
I'd like to see PASS die simply because of the confusion we see in the
help lists. PASSTHRU is intended to replace it for most peoples intended
usages.
PROXYPASS not being documented to date has been a stroke of luck. It's
behaviour can be modified only slightly and without affecting any
correct configurations which already should have originserver and
login=PROXYPASS.
Which would bring it back to two officially supported for 3.2:
PROXYPASS synthetic WWW-Auth if originserver
PROXYPASS synthetic Proxy-Auth if not originserver
PASSTHRU semantic transparency
... and we deprecate login=PASS as replaced.
PROXYPASS -> WWW+Proxy authentication passed along as-is. Proxy
authentication converted to WWW authentication if WWW auth not present.
If neither proxy of WWW authentication present then external_acl auth
added as basic WWW auth (maybe this should have higher priority than
proxy auth here...)
sigh. Did I miss the ext_acl appending there. ...back to documentation
additions :(
If peer is an origin server then we should perhaps strip Proxy auth from
the outgoing request. Could also do this by default in PROXYPASS to make
the difference between the two more obvious, making the rules as follow:
This is what is _now_ happening when PROXYPASS is specified: Proxy-Auth
is only passed in its WWW-Auth form if that translate is hit.
Before this addition PROXYPASS was semantic transparent for Proxy-Auth
and as you describe for WWW-Auth. Depending entirely on the
'originserver' flag.
!originserver+PASS: Proxy & WWW auth passed along as-is. If not
Proxy-auth present then add external acl auth credentials as basic proxy
auth.
originserver+PASS: WWW auth pased along as-is. Maybe external_acl
credentials as well (priority?)
see above re: PASS.
originserver+nothing set: No auth passed along (not trusted).
aye.
PROXYPASS: WWW-auth passed along as-is. If no WWW-auth present then
convert either Proxy-Auth or external acl credentials to Basic WWW auth.
aye.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE18
Current Beta Squid 3.1.0.13
