On Tue, 28 Jun 2011, Wu, Mandy wrote:
Please ignore previous patch, which I did not clean the test code. Sorry. This one is more clear.
Thanks. I've only taken a quick look so far, but I'll dig deeper soon. (I'm in low power mode for a few weeks ahead since I'm on summer vacation...)
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? You don't seem to introduce a way to explicitly ask for NTLM_SSO which to me seems to imply that you will break old behaviors. Or am I 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. 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.) (A first shot would record a live actual use of ntlm_auth and save that "correspondence" as a test case.) 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.
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
