BEEM - Android XMPP

Oops. Looks like my session got timed out while creating this bug report. This is mine. Can someone with superpowers make me the owner? :-p (Or just leave it if it doesn't really have ramifications on this reporting system.. I don't know.)

Thanks!

Anonyme wrote:

When I set the JID to 555 in Beem (with the option to "Use my full JID as username" in either setting), I see a convo with my XMPP server that is like:

The jid is in the form user@domain so just 555 is wrong. In this case 555 is considered as the domain, and the xmpp client try to connect to 555 which failed either with no connection at all or with the <host-unknow> error

When I set my JID to the form of 555@sub.myname.net with "Use my full JID as username" off I see something like:
[...]
There, "NTU1NTU1VTlKTnhGb2JCRmp5RW1FSg==" is the base64 encoding of "555555U9JNxFobBFjyEmEJ", with 555 being my JID before the @ and "U9JNxFobBFjyEmEJ" being my example password.

When I set my JID to the form of 555@sub.myname.net with "Use my full JID as username" on I see something identical to the previous, except the base64 encoding translates to: "555@sub.myname.net<NULL>555@sub.myname.net<NULL>U9JNxFobBFjyEmEJ" (WITH delimiters).

In Beem, the option "Use my full JID as username", only change the variable username. This is exactly the same code so you should have delimiters in both case. However, I just looked at the code with no real try as I do not have a server which supports only PLAIN SASL to test my assertion.

Finally, when I use my Desktop PC and Jabber, using all normal settings, I see something like:
[...]

This base64 encoding translates simply into "<NULL>555<NULL>U9JNxFobBFjyEmEJ" with no domain and no duplicated JID. This is the only thing that authenticates successfully against my server.
(Note that I also don't understand how the server is supposed to discern between the end of the JID and the beginning of the password with the auth stanzas from Beem, since they lack the NULL byte delimieters, but maybe I'm missing something..)

Regarding this you don't have to set the "Use my full JID as username" option to login with Beem.

PS:
Looking at RFC 4616 (the spec for PLAIN SASL AUTH), the format of the auth XMPP stanza's base64-encoded contents should be "authzid<NULL>authcid<NULL>password", where the relationship between authzid and authcid are described as follows (sorry if this is remedial.. these are new terms to me):

[...]

Looking at my code, it looks like authzid is disregarded. So it seems this whole problem is fixed by allowing some way for the transmitted base64-encoded string to read "noonecares<NULL>555<NULL>U9JNxFobBFjyEmEJ"

The authzid element is optional but the first <NULL> is mandatory. You should not set the noonecares because the server may use it to decide if you have the right to login as noonecares.

So this may be a bug in Beem with the PLAIN SASL mechanism. I will comment on this when I will be able to investigate more.

Thanks! We're totally on the same page and I agree completely with your assessment.

Frédéric Barthéléry wrote:

The authzid element is optional but the first <NULL> is mandatory. You should not set the noonecares because the server may use it to decide if you have the right to login as noonecares.

Point taken. That should have been "my server doesn't care". Also, re the "you should not set" part, I'm sorry to say I put in my best effort (a couple of hours) trying to track down the place in the code that needed patching so that I could be helpful and submit my own fix along with this report, but I came up emptyhanded. (Thus the session timeout in the interim.) As a result, I think I have to leave it to you guys to go about not setting the noonecares. :-\

Hi Frédéric,
I seem to have missed your update earlier this month (but I just saw this now). I'm not sure I understand your comment 4. Could you clarify (as I'd like to learn and patch my server if there's a bug on my end..)? Maybe I'm forgetting exactly what the problem was because it was a while ago, but I could have sworn the issue was that when "Use my full JID as username" was turned off, the NULL bytes were mysteriously missing from the authentication strings Beem was transmitting after base64-decoding it..

We are agreed that "authzid<NULL>authcid<NULL>password" is correct.

Thanks,
Mike

Both "authzid<NULL>authcid<NULL>password" and "<NULL>authcid<NULL>password" forms are correct. In Beem, we always use the first form event if "authzid==authcid" . This is the behavior you describe in the bug report.
But Gajim uses the second form if "authzid==authcid".

I think we misunderstood each other (aka my bug report was flawed/unclear)... But I officially have no idea what's going on any more. I actually had the misfortune of losing my Droid two days ago, but I just tried Beem 0.1.7 on my PC's Android emulator logging into my XMPP server (which hasn't been updated) and it suddenly worked. So I give up. But in a good way, I guess, because I can presumably use Beem now once I get my new Droid. :-)

Thanks for looking into this!

Good news then :-)