Re: NA - token = fatalf

On 02/12/2013 08:48 PM, Amos Jeffries wrote:
> On 13/02/2013 3:00 p.m., Alex Rousskov wrote:
>> On 02/12/2013 06:41 PM, Amos Jeffries wrote:
>>> On 13/02/2013 11:33 a.m., Henrik Nordström wrote:

>>>> Squid-2 negotiate expects
>>>>
>>>> NA<SPACE>blob<SPACE>message<NEWLINE>
>>>>
>>>> but do not require any of them to be present.

>>>> NTLM is slightly different and do not expect a blob. Simply
>>>>
>>>> NA<SPACE>message<NEWLINE>
>>>>
>>>> where message may be blank.

>> In the NA case, the
>> helper returns something like NA NT_STATUS_NO_SUCH_USER *\n
>> Is that a valid NA response?
>
> Looks like it should be correct.
>
> Yes .... ERR token="NT_STATUS_NO_SUCH_USER" message="*"

The admin does not want to emit the token AFAICT.
The admin wants NT_STATUS_NO_SUCH_USER to be the message.

My understanding is that if they change the response to new ERR
message="NT_STATUS_NO_SUCH_USER" then a patched Squid will work, but I
do not yet know whether they can change the helper. A bigger question, I
think, is whether the quoted tokenless NA response used to work. If it
used to work, we may have to preserve the old behavior even if this
particular admin can change the helper script.

> I spy the HelperReply.cc parse() "NA " case is not converting the
> responses. AF is doing so, but not NA. Neither is the Negotiate switch
> case. This would seem to be the main bug.

You may be right, but I cannot propose a fix because I do not know what
the correct/supported format(s) are. Thus, I am focusing on preventing
crashes and hoping that somebody who knows what old helpers produced can
fix the parser to accommodate those cases and fix the wiki page.

> IIRC that was left because there was confusion over how to handle
> multi-word messages and optional token prefix.

It feels like that confusion still exists, but I do not know enough to
help, unfortunately.

> Questions are:
> do we assume that there is no token on NA and send the whole string as
> visible error message? The proposed patch will do that.

I think that is a reasonable assumption going forward, but I do not know
whether it is compatible with old helpers.

> Do we try to check the first word and see if it is possibly a token and
> use it as one when is found?

How can we distinguish a token from a message when kv-pairs are not used?

> Or, always assume the first word is a token and send it as one? that
> would probably break NTLM so we would have to do it in the Negotiate
> swicth case. But would allow us to send the catenated token+message for
> error display in case we got it wrong and a FUD token in Negotiate
> should not hurt.
>
> ... and yes these are blind guess ideas. I have not investigated any
> side effects.

I think there are at least two distinct areas here:

1) Old helpers (presumably not modifiable): We should do our best to
support them. We need to know (and document) what their assumptions were
to support them. I do not know that.

2) New helpers (presumably still modifiable): We should require kv-pair
based format for tokens and messages for all new result codes. We may
add new result codes to resolve ambiguous cases in (1), if any. My
understanding is ERR is the only new result code right now.

>> If the token is required for NA/ERR responses, then the helper is broken
>> because it does not send one. If the token is not required, then Squid
>> is broken because it requires one. Henrik says the token is not required
>> [in Squid2].
>
> It seems to be sending token "NT_STATUS_NO_SUCH_USER".

It is trying to send NT_STATUS_NO_SUCH_USER message.

> Henrick only said these two were valid:
> NA \n
> NA token message\n

Henrik also said "do not require any of them to be present" but it is
not clear to me whether "NA foo\n" means that foo is a token or message.

> Although I would go so far as to add this one is probably valid also:
> NA token\n

or

  NA message\n

?

Thank you,

Alex.
Received on Wed Feb 13 2013 - 16:54:59 MST