Closed Bug 954635 Opened 10 years ago Closed 10 years ago

No longer able to log into Facebook Chat via Instantbird since patches enabling JS XMPP

Categories

(Chat Core :: XMPP, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bugzilla, Assigned: florian)

References

Details

(Whiteboard: [1.2-blocking])

Attachments

(3 files, 1 obsolete file)

*** Original post on bio 1203 by Michael <Prescience500 AT gmail.com> at 2011-12-09 21:13:00 UTC ***

Immediately after I updated Instantbird to the new nightly that uses the new JS XMPP, Facebook Chat broke. I can no longer sign in. The account manager returns the following error: Not Authorized (wrong password?)

Facebook Chat was logging in just fine before the change.
*** Original post on bio 1203 at 2011-12-10 14:17:31 UTC ***

Are there any special characters in your password (or facebook username) that could be miss-handled by the new JS-XMPP code? Maybe accentuated characters? Or punctuation?

This bug sounds like something we should try to fix as soon as possible, but it's impossible without a way to reproduce it :-/.
*** Original post on bio 1203 by Michael <Prescience500 AT gmail.com> at 2011-12-10 20:22:30 UTC ***

The password is the same between my Google talk and Facebook accounts and the Google Talk account logs in just fine. If you still want more details on my password, I'd rather do it privately via email or something.
*** Original post on bio 1203 at 2011-12-10 21:02:05 UTC ***

(In reply to comment #2)
> The password is the same between my Google talk and Facebook accounts and the
> Google Talk account logs in just fine.

The authentication mechanisms for Google Talk and for Facebook chat are different.
Google talk ensures the connection is encrypted and then transferts the password in plain text inside the encrypted connection.
For Facebook chat however, the connection isn't always encrypted, so the password isn't sent in plain text in the connection, instead a hash (derived from the MD5 algorithm) is sent.

I suspect the cause of this bug is an issue related to encoding in the hashing algorithm we use.

> If you still want more details on my
> password, I'd rather do it privately via email

I would still appreciate to know which kind of non-alphanumeric characters your password contains.

I understand this can be sensitive information, a private email is fine in this case.

By the way, thanks for reporting this issue! :)
*** Original post on bio 1203 as attmnt 1080 at 2011-12-12 11:58:00 UTC ***

Handle the username and password as UTF8 encoded for the DIGEST-MD5 algorithm. The change to the cnonce code wasn't strictly necessary, but it seemed passing a decimal value to the md5 function in an "aString" parameter was an abuse, so I changed it to use the twitter code.
Attachment #8352822 - Flags: review?(clokep)
Assignee: nobody → florian
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment on attachment 8352822 [details] [diff] [review]
Patch handling non-ascii characters in passwords

*** Original change on bio 1203 attmnt 1080 at 2011-12-12 12:08:26 UTC ***

Looks fine. Is the spacing on the createInstance proper, I thought we align it with the [ from the above line? (Keep my r+ and change it before pushing if not.)

I'd prefer not to duplicate code, but making a nonce function is probably overkill.
Attachment #8352822 - Flags: review?(clokep) → review+
*** Original post on bio 1203 at 2011-12-12 14:39:38 UTC ***

(In reply to comment #5)
> Comment on attachment 8352822 [details] [diff] [review] (bio-attmnt 1080) [details]
> Patch
> 
> Looks fine. Is the spacing on the createInstance proper, I thought we align it
> with the [ from the above line? (Keep my r+ and change it before pushing if
> not.)

This may be a bit better. I don't know any way to indent that I really like in this specific case...

> I'd prefer not to duplicate code, but making a nonce function is probably
> overkill.

I would happily make that a separate function if that made it reusable, but creating a new js module just for it seems overkill.

Fix pushed as https://hg.instantbird.org/instantbird/rev/a6c5dc1dc201

I've tested this by changing the password of my facebook test account to something containing accents. I couldn't connect with the existing code; I can connect with this patch applied. However, the libpurple XMPP implementation isn't able to connect with that password containing accentuated characters, so I'm not sure that what I fixed is exactly the issue described in comment 0.

Michael, could you please tell us if your problem is fixed with the next nightly?
Blocks: 954603
*** Original post on bio 1203 by Michael <Prescience500 AT gmail.com> at 2011-12-13 04:38:12 UTC ***

The problem is not fixed in the latest nightly build: 20111213041511

Florian, I sent you the email about my password. Am I to understand that Facebook Chat is working for other people, including yourself? Is it possible that this is caused by my Facebook settings? If so, do you have any suggestions regarding what I should try changing? If not, how else can I help further?
*** Original post on bio 1203 at 2011-12-13 10:42:31 UTC ***

(In reply to comment #7)
> The problem is not fixed in the latest nightly build: 20111213041511
> 
> Florian, I sent you the email about my password.

I've received it, thanks! I don't think this password should cause any problem though :-/.

> Am I to understand that
> Facebook Chat is working for other people, including yourself?

Yes. It works as well as it has worked in the past (that is, Facebook's XMPP servers aren't very reliable).
You are the only one reporting that you can't login with the new code.

> Is it possible
> that this is caused by my Facebook settings? If so, do you have any suggestions
> regarding what I should try changing?

I don't know :(.

> If not, how else can I help further?

The debug logs (visible in the error console if you set purple.debug.loglevel to 2 from the advanced configuration editor) may help. Only the last few messages before the connection error should be enough to see what the Facebook server is actually replying.

Also, JS-XMPP is currently used only for Facebook Chat and Google Talk account. The previous implementation is still used for generic XMPP accounts. Can you try configuring another account with XMPP as the protocol, your username and chat.facebook.com as the server? This should help verify that it's not just an issue on facebook servers that appeared at the same time as we changed our code.
*** Original post on bio 1203 by Michael <Prescience500 AT gmail.com> at 2011-12-14 03:34:08 UTC ***

I tried using a generic XMPP account setup for Facebook Chat and it works fine. Only the JS-XMPP Facebook Chat is having any issues. I followed your instructions on getting error data. I'm posting it to this bug report immediately after this post.
*** Original post on bio 1203 as attmnt 1082 by Prescience500 AT gmail.com at 2011-12-14 03:39:00 UTC was without comment, so any subsequent comment numbers will be shifted ***
Component: General → XMPP
*** Original post on bio 1203 at 2012-01-30 11:48:04 UTC ***

The error log in attachment 8352824 [details] (bio-attmnt 1082) looks exactly like if the password entered was wrong.
If you are sure the password is right and can still reproduce, I've no idea of what the cause could be.
*** Original post on bio 1203 by Psykar <psyker7 AT gmail.com> at 2012-06-13 14:03:16 UTC ***

I've just been able to reproduce this when updating from 1.1 to 1.2a1pre (20120613042726)

Facebook was logging in fine on 1.1, in 1.2 I get the Not authorized error, without touching the account.
I've tried removing the account and re-adding it.
I have a few standard punctuation characters in my password, nothing particularly special though.

I'll see if I can find some instructions for getting a dump/log somewhere...
*** Original post on bio 1203 by Psykar <psyker7 AT gmail.com> at 2012-06-13 14:29:14 UTC ***

I've also tried changing the facebook security settings to see if that made a difference:
* with and without application specific passwords, 
* with login approvals both enabled and disabled
*** Original post on bio 1203 at 2012-06-13 14:31:49 UTC ***

(In reply to comment #12)
> I've just been able to reproduce this when updating from 1.1 to 1.2a1pre
> (20120613042726)
> 
> Facebook was logging in fine on 1.1, in 1.2 I get the Not authorized error,
> without touching the account.
> I've tried removing the account and re-adding it.
> I have a few standard punctuation characters in my password, nothing
> particularly special though.

Unfortunately no developers have been able to reproduce this. We'd need to inspect the differences being sent by the old 1.1 version of the Facebook protocol and the new 1.2a1pre version...(I'd suggest wireshark, but it's over SSL, so that won't work).

Florian suggested that, if he could reproduce, the way forward would be to add some printfs into the old libpurple code and make sure the password is being encrypted in the same way.
*** Original post on bio 1203 by Psykar <psyker7 AT gmail.com> at 2012-06-13 14:45:00 UTC ***

I've just made a new FB account which I am happy sharing the username and password via private email/IM
I can reproduce the issue with this account running version 1.2a1pre (20120613042726) on Windows 7 x64

Steps done to create FB account:
enter name: louis tester
enter email: <redacted>
enter password: <redacted>
enter sex: <male>
enter bday: Jan 1 1987

Confirm the email address (via link in email)
Verify the account with a real mobile number (since removed from the account) by going to account settings -> username (it asked me to verify there)
Enter code received on mobile, go to mobile settings, remove mobile number.
Choose a username for the account: PsykarTest

I can log on to FB chat using pidgin now with the username PsykarTest and pword <redacted>
InstantBird does not work - "Error: Not authorized (Did you enter the wrong password?)"
Error console only has "chat.facebook.com : server does not support RFC 5746, see CVE-2009-3555" (but I haven't found instructions to enable a higher debug level yet.

Feel free to email me directly for the password to the account (as FB traces a few things like geolocation I'd prefer not to share too easily :P )
*** Original post on bio 1203 at 2012-06-13 14:53:16 UTC ***

I'm very interested in testing this (although I can't promise I'll be able to get to it today). My email is florian AT instantbird DOT org.

By the way, if you want to discuss things you are testing directly with us (or just share ideas/some feedback or even just watch our discussions), you are welcome in our IRC chatroom: #instantbird on irc.mozilla.org
Attached patch Patch (obsolete) — Splinter Review
*** Original post on bio 1203 as attmnt 1603 at 2012-06-14 11:25:00 UTC ***

The problem is that we are supposed to normalize the node part of the JID to lower case characters and didn't do it. Libpurple also converts the domain part to lowercase, I think that makes sense so I did it too, although I haven't found the specification saying we need to do it for the domain part too.
Attachment #8353360 - Flags: review?(clokep)
*** Original post on bio 1203 at 2012-06-14 12:11:41 UTC ***

Comment on attachment 8353360 [details] [diff] [review] (bio-attmnt 1603)
Patch

>diff --git a/chat/protocols/xmpp/xmpp.jsm b/chat/protocols/xmpp/xmpp.jsm
>@@ -838,18 +838,27 @@ const XMPPAccountPrototype = {
>   _parseJID: function(aJid) {
>     let match =
>       /^(?:([^@/<>'\"]+)@)?([^@/<>'\"]+)(?:\/([^<>'\"]*))?$/.exec(aJid);
>     if (!match)
>       return null;
> 
>-    return {jid: match[0], node: match[1], domain: match[2],
>-            resource: match[3]};
This has four fields: jid, node, domain, resource.

>+    let result = {
>+      node: match[1].toLowerCase(),
>+      domain: match[2].toLowerCase(),
>+      resource: match[3]
>+    };
>+    let jid = result.domain;
>+    if (result.node)
>+      jid = result.node + "@" + jid;
>+    if (result.resource)
>+      jid += "/" + result.resource;
We don't use jid here?
>+    return result;
This has three fields: node, domain, resource.
>   },

Did you forget to add jid to the result?
*** Original post on bio 1203 as attmnt 1604 at 2012-06-14 12:15:00 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8353361 - Flags: review?(clokep)
Comment on attachment 8353360 [details] [diff] [review]
Patch

*** Original change on bio 1203 attmnt 1603 at 2012-06-14 12:15:36 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8353360 - Attachment is obsolete: true
Attachment #8353360 - Flags: review?(clokep)
Comment on attachment 8352822 [details] [diff] [review]
Patch handling non-ascii characters in passwords

*** Original change on bio 1203 attmnt 1080 at 2012-06-14 12:17:24 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8352822 - Attachment description: Patch → Patch handling non-ascii characters in passwords
Comment on attachment 8353361 [details] [diff] [review]
Patch to handle upercase characters v2

*** Original change on bio 1203 attmnt 1604 at 2012-06-14 12:19:35 UTC ***

This looks better. :)
Attachment #8353361 - Flags: review?(clokep) → review+
*** Original post on bio 1203 at 2012-06-14 13:28:10 UTC ***

Psykar, thank you very much for the test account that could reproduce this bug!

Just to make it completely clear, the problem can be reproduced whenever someone configures a Facebook Chat account with a username containing upper case characters.

Fixed: https://hg.instantbird.org/instantbird/rev/fd5e9bf51bf6

Michael, it would be nice if you could confirm that it works for you with a build including this fix (nightlies built starting from tomorrow)! :)
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
OS: Linux → All
Hardware: x86 → All
Resolution: --- → FIXED
Whiteboard: [1.2-blocking]
Target Milestone: --- → 1.2
*** Original post on bio 1203 by Psykar <psyker7 AT gmail.com> at 2012-06-16 16:01:09 UTC ***

Works for me, thanks.
You need to log in before you can comment on or make changes to this bug.