opened
igor-ba
username_0
First of all, let me thank your for your project, it really helped me a lot! 
The improvement that I suggest covers the case where authentication was not successful, but you need to know the user name for further processing. Sure, I could also parse args for the debug function, but this additional complexity is unnecessary, if I could get the user data directly.
So what do you think on this PR?
add user data even if connection is forbidden
issue
created
einfallstoll
username_1
I appreciate your proposal, but I'm still undecided wether this would break backward compatibility or not. As it will call the `forbidden` function, it would just expose the NTLM-data to this function. Would someone check for `request.ntlm` in that function to see wether the module fucked up?
comment
created
igor-ba
username_0
This is basically the reason for the PR: to be able to check in forbidden function who failed the auth challenge. Failing to authenticate (e.g. due to typo in password) to NTLM might cause problems not only for this server, but also for file shares, corporate proxies etc. That is why I need in my case proper error message with at least user name + domain in it. 

Regarding the backward compatibility: this change affects only behavior of `forbidden` function, extending its parameter with additional fields. It could affect only code that explores `request` or `response` objects. I doubt that anyone puts such a complexity to the `forbidden` function.

I would also be fine with introducing the user data only once as `request.ntlm` to reduce the risks. However this would make its behavior inconsistent compared to the normal case of successful authorization.
comment