Facebook-chat-api: Cannot login using login approvals and 2FA or otherwise

[Alcap]

Hi,

I've stopped my bot for a new release and when I went to login again I got the following message:Error inside first pull request. Received HTML instead of JSON. Logging in inside a browser might help fix this.

This was using the appstate.json to login. I've since tried to login again "fresh" to no avail and I've also tried disabling 2FA and login approvals, and the end result of that is that my account is locked out without ever actually logging in.

Is anyone else having this issue or is it just me? Can anyone help me in increasing the debug for this so, hopefully, I can fix it?

Thanks!

[DanH42]

I just started seeing this today as well, after my appstate.json was mysteriously invalidated for the first time in months. I can log into my account normally in a web browser (from the same IP address, using the same UA string), but when I start the bot, it gets hit with this message.

I'm not super familiar with this library's internals, but based on the past couple minutes of trying to replicate the issue in a real browser, it looks like this may be related to the Very Hacky Part of makeLogin in index.js. Notably, when I load up https://www.facebook.com/ in a fresh Incognito session and look at the page source, I only see 3 instances of _js_, none of which are related to cookies. I don't know what this initial page load used to look like prior to today, but I'm currently only seeing two cookies set by the response headers (fr and sb). Once the page finishes loading, I can see two additional cookies that are set: wd, which is set via javascript and contains my screen resolution, and datr, which is set in a response header from a request to a tracking pixel at /common/referer_frame.php and contains a random code formatted in the same was as the sb cookie. That same tracking pixel also sends a header to clear a cookie called _js_datr, which sure enough, is somehow being briefly set after the initial page loads, even though that string doesn't show up anywhere in the HTML The value of this _js_datr cookie is identical to the datr cookie being set by the tracking pixel. If I search the page for the value from that datr cookie, it shows up inside a hidden input called reg_instance inside a form with the title "Security Check" and a ReCaptcha challenge underneath. My guess is that if you try to log in without the datr cookie set, you'll be served with that form and asked to help train Google's self-driving cars for free to prove you're a human.

I don't really know where to go from there, but that's what I've got so far.

[7osCraft]

It looks like facebook made a sudden change that caused this issue.
@DanH42 Thanks for your investigations!

We set the datr cookie using the normal cookie header sent by Facebook, but as you said, there's a value for it in a hidden form input. So i'm not sure if it's the same one sent by the cookie header.
I'll look more into this and see if I can come up with a fix.

[7osCraft]

Looks like the problem is gone. I was able to login using the api without any problems now.

[DanH42]

It looks like they're A/B testing it. If I visit the login page in an Incognito window and refresh it a few times, clearing my cookies in between, some of those sessions have _js_datr in the page source and others don't. That could mean they're still slowly rolling it out, or maybe they've reversed course and they're rolling it back. Something to keep an eye on, at least.

What follows _might_ just be related to my account, so feel free to skip over the rest of this message, but I wanted to publicly document it just in case someone else sees the same symptoms and it turns out to maybe be related after all.

Anyway, I tried logging in again, and that's where things get weird. To my surprise, the appstate.json file that I've been using for the past 10 months worked this time, so I didn't have to fall back to password authentication at all. It took a bit longer than usual to log in -- 51 seconds between Request to pull 2 and Request to thread_sync. Once it finished logging in, I wasn't receiving any incoming messages, and trying to send a message resulted in an error:

ERR! sendMessage TypeError: Cannot read property 'reduce' of undefined
ERR! sendMessage     at /home/node/node_modules/facebook-chat-api/src/sendMessage.js:157:51
...snip...

FWIW, I'm running the latest 1.7.0 release from npm, and _not_ the current git master that has the simplified MQTT code.

I logged in through a normal browser, and was prompted to complete a security check. They emailed me a 6-digit code, and I was allowed to log in. After doing that, I figured I'd try restarting the bot. It took about a minute to log in again, and the moment I got Done logging in, the page I still had open in my web browser popped up a notification that I'd been "temporarily restricted from tagging people" for the next 12 hours (???). This time around, the bot still can't see any incoming messages, but now it's able to send outgoing messages.

It's hard to tell which parts of the behaviors I just saw are Facebook's security systems detecting unusual activity with my account, and which parts are changes to the login process that are still being A/B tested. I suspect it could be a little of both, and I don't really want to mess around with it anymore today and risk losing my account. If things are still acting strange once the weekend rolls around, I might take a deeper dive with some Whitehat accounts.

[N0NameN0]

hi,
same here seems to be fixed. BTW how do you guys use this lib to avoid FB to "block" your account and force you to change password ?

[Alcap]

It seems the issue has resurfaced... Anyone else experiencing it?

Thanks!

[nishancx]

Yes, the same thing is happening with me.
I tried with a new facebook account too, but didn't work.