cURL / Mailing Lists / curl-library / Single Mail

curl-library

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

From: Wu, Mandy <mandy.wu_at_intel.com>
Date: Tue, 28 Jun 2011 22:04:35 +0800

On Tue, 2011-06-28 at 05:26 +0800, Daniel Stenberg wrote:
Daniel, Thanks for your quick response.

> 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.

> It struck me that there's a rather nifty approach we can use to test this:
>
> 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 .

> B) If libcurl is built with DEBUGBUILD defined, the code will use getenv() to
> figure out the tool to invoke (instead of ntlm_auth). Let's call it
> fake_auth for now.
>
> 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?
> (A first shot would record a live actual use of ntlm_auth and save that
> "correspondence" as a test case.)
I should look more deeper at existing test cases to figure out how to generate/use these files.
> D) Now we can write up tests that the single-sign-on code fully, for both
> successful and unsuccessful cases and for out of memory cases etc.
>
> Comments?

> And speaking of out of memory cases:
>
> > + username = strdup(user);
> > + slash = strpbrk(username, "\\/");
>
> This will crash when strdup() returns NULL. The code has several more places
> where it doesn't check the return codes for memory operations where it should
> to keep our standards.
>
> Ideally, some of the new function calls this patch introduce should also be
> added to memdebug.c so that we can properly test them failing as well as
> making sure that they don't leak.
I will fix these memory cases first.

Thanks,
Mandy

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