Facebook-chat-api: Account locked out for suspicious activity

[featherbear]

For about a month now, my account has been recurringly locked out for suspicious activity - and I am required to change my password and go through a security check every time.

Inevitably that makes this this library unusable for long-running scripts.

Just wanted to know if anyone else is getting this issue?
Issue seems to be evident on the fbchat Python library too

[Schmavery]

The standard question: what are you doing in your script?

[featherbear]

It's currently just listening for prefixed messages, to which it then does something

  api.listen((e, m) => {
    ...
  }

[ravkr]

I'd like to add, that although currently I don't use facebook-chat-api, my bot-account also gets locked when e.g. using youtube-dl (to download a video using that account) - even if its only one video
symptoms are the same: I'm forced to change my password, go through a security check etc.

so maybe Facebook have updated bot detecting mechanisms :(

[mrx23dot]

Any solutions? This is serious issue.

[Schmavery]

How often do you login? One thing we've noticed is that people get blocked less when they log in using app state (explained here in the 3rd example: https://github.com/Schmavery/facebook-chat-api/blob/master/DOCS.md#logincredentials-options-callback)

[featherbear]

I've got both the appstate/cookie login and the username password fallback in the code

App state logons (and fallback U&P login) are very rare, and only happen when the server reboots

[featherbear]

I just tried using the example code for listening to a chat - but issue persists.

const fs = require("fs");
const login = require("facebook-chat-api");

login({appState: JSON.parse(fs.readFileSync('appstate.json', 'utf8'))}, (err, api) => {
    if(err) return console.error(err);

    api.listen((err, event) => {
        if(err) return console.error(err);

        console.log(event)

    });
});

When the user gets locked out, the info log lines start to flood the chat

[mrx23dot]

I think i get locked out because the server is in another country, and i login with same credentials on my desktop. If i keep logged in on both sides it doesn't seem to be an issue.

[featherbear]

Well this is from logging on at a computer in my house - haven't tried my actual computer though

[nemoryoliver]

I am getting the same issue. I believe facebook made changes recently. I hope there's a way to get around this.

[DentFuse]

I don't seem to be having any problems as such. I have been using this for about a month now without any problems. My account did get locked a couple of time but that was because I had deployed my code to Heroku, which of course had server in other countries. Now I run my bot 24-48 hours at a time on my own server at home with no problems.

What are you doing in your code? How often do you logout and relogin? And most importantly how often does your code send requests to Facebook? As @Schmavery said, using appstate to login is really helpful, I rarely have to login with my username pass once my app has written appstate.

[goldlil]

Same problem here, one account was temporary locked, for second one after every login I need to change password and can't use app with app state. Currently I'm just doing logging in with api. My code is not deployed yet, I'm running it on localhost could that be a problem?

[gamelaster]

I can agree too, my bot which was used very long time ago as bot is frequently locked when login in (via browser), it's really strange.

[jamesmoessis]

Same issue here. I am running my code from an AWS server from my home city as well. It usually lasts for a little bit but then gets locked out. Too many requests? Does listen() just poll the chat a bunch of times? Can we slow down the poll frequency? Can we use a webhook?

[gamelaster]

Well, As far as I know, the Facebook have kind of "flag", where suspicious accounts being marked this flag and in after any suspicious usage it will lock out the account. I did some tests on my own bots, and this "flag" being activated every time of I log in with my scripts 🙁 Sadly, this project isn't "that lovely library with 600 stars" anymore, it's started being used by spammers etc.

EDIT:
Workaround? Facebook Messenger MQTT API

[nemoryoliver]

@gamelaster that's what I think too... does anyone here knows how to use the MQTT API of fb messenger? Or someone can port this https://github.com/bitlbee/bitlbee-facebook

[gamelaster]

@nemoryoliver There's two MQTT Messenger API implementations. One for bitlbee which you sent and one for libpurple. Anyway, all those implementations are in C, probably you would need to make native module for nodejs, and mostly it will lack many features. I was thinking about making C(++) MQTT Messenger API with implemented most of features and module for NodeJS, but no time for this (+ I'm having issues to sniff the packets from emulator because no iptables on Windows, thank you Microsoft).

[featherbear]

Yohoo, there's also https://github.com/ChatPlug/libfb-js

[nemoryoliver]

Yohoo, there's also https://github.com/ChatPlug/libfb-js

JACKPOT!!!!

[gamelaster]

@featherbear nicee, this looks exactly what I wanted to dooo, great!

[featherbear]

Yeah!

Unfortunately it's not as feature-rich as facebook-chat-api, so looks like I'll be writing my own functions

@Schmavery what do you think of implementing MQTT into your library?

[kedarv]

I think the MQTT and browser lib (Schmavery) are different enough where it wouldn't make sense to implement here.

Thanks for linking libfb-js! This looks exactly like what I was attempting to do myself when I discovered the libpurple repos

edit: unfortunately mqtt doesn't seem to avoid this issue :(

[7osCraft]

I've tried mark as seen when a message is recieved. Also tried to make the ip fixed. With no luck.
I found another thing that I think is linked to this problem.
When you open the "Login and security" page in facebook with the account you use in the api, It doesn't say "Active now" on the location of the api although it is running.
Another thing is Messenger sends active_ping sometimes in the browser.

[Schmavery]

852