Review Request 129248: Distinguish between NULL and empty domain in NTLM authentication

[David Faure]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129248/#review100220
-----------------------------------------------------------


Ship it!




Seems reasonable to me, if indeed both need to be supported then I don't see a better way.

- David Faure


On Oct. 23, 2016, 6:23 p.m., Krzysztof Nowicki wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129248/
> -----------------------------------------------------------
> 
> (Updated Oct. 23, 2016, 6:23 p.m.)
> 
> 
> Review request for KDE Frameworks, Dawit Alemayehu and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> -------
> 
> The default KNTLM behaviour when the client supplies no domain name is to use the target name provided by the server. This however prevents from explicitly using an empty domain name.
>     
> The change makes use of the fact that QString can be either NULL or empty and retains the old behaviour if the domain name is NULL (for ex. "username"), but when a valid empty string is provided (for ex. "\username") the empty domain name is used instead of the target name.
>     
> This fixes some rare authentication failures for oddly configured servers.
> 
> Autotests have been updated to reflect new behaviour.
> 
> 
> Diffs
> -----
> 
>   autotests/http/httpauthenticationtest.cpp a4367404003bff6b60cbfe633385125df8820a4e 
>   src/kntlm/kntlm.h 5e0c2be6ad4dd62705da038f70fbbc4daacd60fb 
>   src/kntlm/kntlm.cpp 269204e3c1d0a4615afefe385047ba54231ecaa6 
> 
> Diff: https://git.reviewboard.kde.org/r/129248/diff/
> 
> 
> Testing
> -------
> 
> Executed autotests including updated test cases.
> 
> 
> Thanks,
> 
> Krzysztof Nowicki
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20161023/1895daee/attachment-0001.html>