cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: [PATCH]Add NTLM single-sign-on support by using /usr/bin/ntlm_auth

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Wed, 29 Jun 2011 22:41:42 +0200 (CEST)

On Tue, 28 Jun 2011, Wu, Mandy wrote:

>> A question: if libcurl is built to support NTLM_SSO, how would it still be
>> able to support existing programs that does NTLM the old way?

> Current design is to do single-sign-on only when password is empty. That
> means if client provide a password, it will do NTLM the old way. It
> shouldn't break the old behaviors since the old NTLM will need password
> anyway. Correct me if I am wrong.

I don't think there is anything that forbids a zero length password from being
used for NTLM, except by policy. I'm kind of leaning towards preferring adding
a bit in the CURLAUTH_ range named CURLAUTH_NTLM_SSO to be more explicit and
avoid the fringe case where someone actually wants a blank password.

>> A) We build a "fake" ntlm_auth executable for testing purposes.
> Actually there is a simple test hack at
> http://david.woodhou.se/ntlm_auth_v2.c .

Oh right. That's a rather fancy version of a "simple test hack" though, my
thinking would be a version that would simply send pre-written strings back so
that the test cases etc would be perfectly repeatable.

>> C) fake_auth would accept commands like ntlm_auth does (and save them to a
>> file) and respond with fixed response strings read from the data/test*
>> file. (We have both C code and perl code that grok the XML-like format.)

> Why need to save input/output to a file? The above test hack "acts" the same
> as the real ntlm_auth tool, can we just get response from its output?

If we store exactly what libcurl sends to it and reads from it, we can verify
exactly that in the test case. If not, we can only verify that the end result
is fine.

Sure, we can also just verify that the response from the fake_auth is fine,
but that would move checking logic to the fake_auth instead of keeping it in
the test case. I would rather keep the fake_auth tool as simple and stupid as
possible to allow more flexiblity and testablity to the test cases, like for
example adding test cases for broken or non-compliant responses etc.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Received on 2011-06-29