Re: [RFC] Unified Squid helper protocols

On 03/12/2011 09:01 PM, Amos Jeffries wrote:
> This is a Squid-3.3 proposal.
>
> I've been looking at transitioning the helpers use the same protocol.
> Firstly by transitioning the response codes to be OK/NA/ERR with
> key=value parameters for additional information.
>
>
> For Basic auth and external ACLs the NA result is added.
>
> ERR being intended for helper errors or problems.
> In the further future this may be used to do re-tries with other helpers.
> NA for explicitly not-authorized. Squid will reject the user with
> Forbidden.

Based on eCAP experience and our deny_info functionality, it may be
better to convert "not authorized" into a more general "block" (BL) or
"deny" (DY). Deny_info will determine what happens when that code is
received. This should be supported for any helper (eventually).

> NTLM/Negotiate changes a bit:
>
> TT becomes OK token=
> AF becomes OK user=
> LD becomes ERR user=
> BH becomes ERR message="some text"
>
>
> The parameter token= is added to represent the base-64 encoded binary
> blob going back and forth. May be used in any of the protocols
> eventually, but initially just Negotiate and NTLM require it.

It feels wrong that the parameter value syntax depends on the parameter
name. Makes it more difficult to add extension (or new) parameters
without breaking (old) Squid. Consider:

    name="string with some documented quoting rules"
    name=valueterminatedbythefirstwhitespace

If some helpers need to pass binary data, they can use the latter format
and base-64 encoding but the low-level value parser in Squid would not
have to know the difference.

You could handle encodings in the low-level value parser as well if you
make them explicit:

    name="string with some documented quoting rules"
    name=base64:base64encodedvalue
    name=rawvalueterminatedbythefirstwhitespace

The latter assumes no raw value can start with "base64:". Other
quoting/encoding mechanisms are possible, of course.

> The parameter message= is added with a quoted string value to allow
> other parameters on the same result line when an error reason/message is
> sent back.
>
> The parameter user= is added to hold the username whenever relevant for
> any reply.
>
> Other parameters are on the planning board for addition after the
> changes. So far I have: ttl= for setting a desired credentials-TTL,
> group= for associating a group name with the user=, tag= extended from
> external ACL to auth.
>
>
> Opinions? problems? other ideas?

I do not know much about existing helpers, but I would recommend using
the same set of basic syntax rules for _all_ messages:

    <responsecodeterminatedbywhitespace> [name=value]*

where the value syntax is as discussed above. This approach would make
writing a general response-buffer-to-response-structure parser easy and
simplify addition of new fields or extensions.

HTH,

Alex.
Received on Mon Mar 14 2011 - 15:48:18 MDT