#459 Unescape JIDs before passing to Cyrus SASL

Running Prosody 0.9.7 on Ubuntu 12.04 LTS, using Cyrus to authenticate users against our Windows 2003 AD.
The one user we have with a space in their username/JID cannot authenticate (one of the company directors, so I'm not keen on having to tell him the user name he's been using for longer than I've been with the company has to be changed), but the same Cyrus configuration with Openfire on the server and the exact same Pidgin client configuration worked just fine.
I am aware of your statement on the XEP page that XEP-0106 is client-side, so it should work, but for me/my user it isn't.

Just to add, the error that Pidgin gives back is "Not authorised" for JIDs with "\20" in them. Other than the account I made as part of the installation, I've not had to make accounts on the server, the mods have taken care of everything beautifully up to this point.

Further to last, I've just been "playing" with testsaslauthd to see if SASLAuthD understands \20, which it doesn't:-
murray@svr-svn01:~$ sudo testsaslauthd -u murray\20c -p xxxxxxxx -s xmpp
0: NO "authentication failed"
murray@svr-svn01:~$ sudo testsaslauthd -u "murray c" -p xxxxxxxx -s xmpp
0: OK "Success."
Clearly, it needs the username passing in quotes with the space as a space. Not sure if this helps any with either diagnosis or correction of the issue.

Last from me for a bit, I've enabled the debug window in Pidgin to check what is going on from it's point of view, and it sends the JID with "\20" in it, which suggests to me that mod_cyrus (?) isn't correctly handling the conversion of the JID to a sensible username. Happy to provide my configs if required.

Thanks for the extensive debugging you've been doing here!
I think whether Prosody "unescapes" the username before passing it to Cyrus is beyond the scope of the specifications, as it's not a protocol issue - it's dependent on how you store your data in your authentication database. And it makes sense to store it unescaped there.
Any chance you could try the attached patch?

More than happy to help in any way I can. Assuming I don't need to restart the server/service, that patch didn't change anything obvious, however I note that the unescape call sits inside a test for set_canon_cb (and there's a logging line straight after it which has not tripped in our current logs), so I guess I need to set a variable somewhere to make it canonicalise the user name?

Spent a little bit more time reading the code (and the config file) and realised that the log hadn't tripped because it wasn't set to debug. Have set such, restarted Prosody to load everything and can report that usernames with spaces are unescaped according to the log; only problem now is that Pidgin still says "Not Authenticated".
Wild guess (I really don't know lua), is the string that's passed to cyrus quoted? (Yes, clutching at straws...)

For "Not Authenticated" above read "Not Authorised" (just noticed while doing a little more testing to see if anything turned up in the Windows Event Logs on the AD; nothing... Would make this so much easier if I could see what is arriving at the AD server to be matched...)

Is the connection between Cyrus SASL and AD over SSL? If not, maybe you could get a packet capture using Wireshark/tcpdump?
Other than that, I'm not sure what to suggest - the canon_cb mechanism is precisely for applying transformations like this, so I think we're in the right place.

FWIW, I'm not sure this was an accurate test:
murray@svr-svn01:~$ sudo testsaslauthd -u murray\20c -p xxxxxxxx -s xmpp
0: NO "authentication failed"
You probably wanted murray\\20c:
% echo murray\20c
murray20c
% echo murray\\20c
murray\20c
Anyway:
If you still have debug logging enabled, I don't suppose you could show concurrent Pidgin debug log and Prosody debug logs from trying (unsuccessfully) to log in?
If it's sensitive, you could send it via email (e.g. to developers@prosody.im), and Matthew knows how to get in touch with me. (I'd suggest emailing it directly to me, but you don't know who I am, and have no reason to trust me :) )

@MWild1 - Hadn't even considered wireshark (doh!). We don't SSL internally and I have a capture now, and TBH I'm even more confused: the LDAP search/bind sequence looks pretty much identical for both the space/no space attempts, and both responses to the bind attempts are "success", so why Pidgin is saying it's a fail I do not know (perhaps it's not Prosody that is "failing" now). I'll have to get concurrent capture/server/client logs I think to progress the debugging.
@paul - The FWIW results are identical for single and double backslash; "authentication failed". As mentioned above, I am going to try getting all three logs/captures and look for correlations. Yes, there will almost certainly be things in those three thaht I wouldn't want going outside the company, but I will get them and go through them as a first step.