aboutsummaryrefslogtreecommitdiffstats
path: root/facebook
Commit message (Collapse)AuthorAgeLines
* Load is_work through FbData, fixes api key issues after the first login.HEADmasterdequis2017-10-17-0/+25
| | | | | I have no idea what request after login requires api keys, though. This plugin signs all post-login requests pointlessly.
* Work chat login support (enable the "work" setting to use it)dequis2017-10-16-9/+467
| | | | | | | | | | | | | | | | | | | | | | | | | | | This covers three autodetected login types: 1. Work account password Simple, very similar to normal account types 2. Linked personal account This is deprecated but still needed in some companies. Looks just like password auth to users. In rare cases there may be more than one work account linked to a personal account, in which case this will only use the first one. Usually they can be de-linked by assigning a password (see the official docs) 3. SSO This one is awkward. The password can be set to garbage and users will receive a PM with instructions to do an oauth-like login, but there's no explicit auth code screen, just a redirect to a fb-workchat-sso://, which probably results in an error. Users are expected to copy that url, hopefully from the address bar. Not very practical, but works! In all cases, the username is the work account email.
* Document the unknownsAbyr Valg2017-10-16-12/+50
|
* Fix "Failed to read thrift" with unknown fields in /t_p payloaddevelopmentdequis2017-08-30-1/+11
| | | | | >Login error: Failed to read thrift: facebook-api.c:1815 >fb_api_cb_publish_pt: assertion 'FALSE' failed
* Fix login hang/timeout when the last page of contacts is emptydequis2017-07-12-1/+1
| | | | | | | | | | | | | | | | | The contact list is fetched in pages of 500, but non-friends need to be filtered out, so you could end up in a situation where the last page of results is all non-friends. The "contacts" signal was emitted for each page of results, and has a flag that says if it's complete, which lets login continue. So when the last page of the contact list is empty (all non-friends) the contacts signal isn't emitted, and login gets stuck forever. This commit changes it so that the signal is emitted with an empty 'users' GSList when it's complete (and when it's an initial fetch, not when when parsing deltas, which doesn't use the 'users' GSList) Thanks to dcxk for finding this and helping debug it.
* Add tweak values 1-15, sets orca version in the user agentdequis2017-07-07-2/+49
| | | | | | | | | | | | | Since there are some issues I can't reproduce, let's do this experiment properly and figure out if this really matters. Value 1 is slightly newer. Value 2 is newer with the current set of fields. Value 3 is what purple-facebook uses. Adding 4 makes it http only, adding 8 makes it mqtt only. Some values are redundant. I suggest trying 1, 2, 3, 7 and 11.
* Add "tweak" hidden setting, does nothing for now.dequis2017-07-07-0/+30
|
* Revert "Makefile.am: add -no-undefined for cygwin"dequis2017-05-29-1/+1
| | | | | | | | | This reverts commit 310de485e9597df35e94cd4020f8b23121cb3904. Turns out it wasn't harmless, and it breaks mac OS. Instead of adding platform checks here, this flag is now included in the cygwin-specific parts of the bitlbee pkg-config file, as of bitlbee commit b9c10a1a (version string 3.5.1+20170529+develop+18-gb9c10a1a-git)
* Makefile.am: add -no-undefined for cygwindequis2017-05-13-1/+1
| | | | | | | | | | Quoting https://cygwin.com/ml/cygwin/2013-07/msg00421.html >despite popular misconception, this flag is harmless on non-PE targets This also depends on changes on the bitlbee side to be able to link to bitlbee itself, see bitlbee commit 54b2a367 (version string 3.5.1+20170513+develop+16-g54b2a367-git)
* Send orca-formatted user agent for all HTTP requests toodequis2017-03-30-9/+19
| | | | | | | | | | | Fixes "Failed to parse thread information" errors when joining channels. Facebook rolled a hotfix update today and they are requiring the same user agent for HTTP requests too. As far as I can see the main affected request is ThreadQuery. Hopefully this also solves issues some a tiny minority of people were still having with sync sequence ids.
* fb_api_http_query: Handle FB_API_QUERY_SEQ_ID in the switchdequis2017-03-29-0/+1
| | | | Last commit was broken
* Use the new ThreadListQuery hash for seq id only, not for thread queriesdequis2017-03-29-2/+12
| | | | | Since it's used for different things and parameters are all wrong with the newer query hash, but the seq id query doesn't use parameters.
* Set the MQTT user agent to look like Orca-Android 38.0.0.22.155dequis2017-03-29-1/+17
| | | | | | | | | | | Looks like this is what they use to discontinue older versions. An empty user agent is treated as too old. This fixes following error when sending messages: This app version no longer supports messaging. To continue to send and receive messages, please update your app to a newer version or use the mobile web version of Facebook.
* Update ThreadListQuery hash, fixes sync_sequence_id issues, thanks Eiondequis2017-03-29-1/+1
| | | | | | | | | | | This hash represents a graphql query cached in the server. We were using an old version of the hash that broke for some reason, possibly related to the fact that fb messenger versions older than 5 are being discontinued. For reference, the oldest parts of the plugin were written when 4 was the latest version, most parts are updated to 33 or 38, and the newest parts are based on 100 or so. Thanks EionRobb for coming up with this fix so quickly.
* Fix crash when the error signal is raised and glib has G_ENABLE_DEBUGdequis2017-02-25-2/+2
| | | | | | | | | | | | | | | | | | | | | | | If glib is built with --enable-debug=yes, it will have G_ENABLE_DEBUG set internally This flag changes the g_marshal_value_peek_object() macro to use g_value_get_object(), which performs sanity checks, instead of doing a direct offset access. The definition of our error signal was wrong, using a marshaller with a GObject in the first parameter but setting the type of the GValue to G_TYPE_ERROR. Since we have no marshaller for G_TYPE_ERROR, and that all of those are functionally equivalent (and in fact use the exact same code in non-debug builds), I went with POINTER for both sides. The actual crash happened because of a g_return_val_if_fail() in the sanity checks which made it return NULL after throwing a warning like this: g_value_get_object: assertion 'G_VALUE_HOLDS_OBJECT (value)' failed This was reported by a gentoo user who had the debug use flag. Thanks!
* Fixed receiving attachmentsKamal Galrani2017-02-24-1/+1
|
* Fix creating threads, inviting, kicking members (misc api changes)dequis2017-02-24-6/+6
|
* Fix setting channel topics (tid=t_id.1234 is no longer valid)dequis2017-02-24-1/+1
| | | | The server expects the tid parameter to be just the tid now.
* Handle new style topic/groupchat membership eventsdequis2017-02-24-7/+132
| | | | | | | | | | | Looks like the mercury topics were deprecated and instead we get these: * deltaThreadName * deltaParticipantsAddedToGroupThread * deltaParticipantLeftGroupThread Also slightly modified the handlers on the bitlbee side to add users directly without requiring a thread fetch, and to show a kick message
* Refactor, split fb_api_cb_publish_ms into ..._new_messagedequis2017-02-24-29/+63
|
* Extract target url from fbrpc:// URLsMickaël Thomas2017-02-23-1/+12
| | | | | | Those URLs seem to be generated when the Android share feature is used. Fixes #97
* Fix some compiler warningsdequis2017-02-23-6/+3
|
* Fix infinite loop in previous commit when being added by a non-frienddequis2017-01-22-2/+8
| | | | | | Because apparently that's a thing that happens (incoming delta with added item saying "friendship_status": "CAN_REQUEST" instead of "ARE_FRIENDS")
* Use FetchContactsDeltaQuery for contact syncdequis2017-01-08-30/+181
| | | | | | | | | | | | | | This has a number of benefits: - Most of the time the contact sync reply will be empty - We can do contact sync more frequently (It's 5 mins now, was 30) - Figuring out what contacts were added or removed is much simpler and less likely to get things wrong. - Non-friends are no longer accidentally removed because there's no need to compare contact lists - On accounts with lots of friends this gets rid of one source of CPU usage spikes - Less load for facebook's servers (lol)
* Refactor, split off sync-contacts timeout code from fb_cb_api_contactsdequis2017-01-07-13/+20
|
* Update some graphql query hashesdequis2017-01-07-6/+21
| | | | And add the FetchContactsDeltaQuery one.
* Refactor, split off contact nodes parsing from fb_api_cb_contactsdequis2017-01-07-11/+26
|
* Don't disconnect when trying to join a chat after being kickeddequis2017-01-07-3/+54
| | | | | | This replaces a subset of "Failed to parse thread information" (the ones that aren't really a problem parsing) with "You have been removed from this chat" appearing in the relevant chat window.
* Refactor, split chat topic string generation to a separate functiondequis2017-01-07-19/+30
|
* Don't fail on groupchats with only two members including selfdequis2017-01-06-1/+3
| | | | | | Those are created by the "Marketplace" feature: http://newsroom.fb.com/news/2016/10/introducing-marketplace
* Set a non-empty HTTP User-Agentdequis2016-11-21-1/+8
| | | | Shot in the dark to fix checkpoint issues, but had to be done anyway.
* fb_api_cb_contacts: Make all the other fields optional toodequis2016-06-06-5/+5
| | | | | | | | | | | | | Fixes #89 (No matches for $.represented_profile.id) Previously, in 4efa397, hugePictureUrl was made optional. Now someone complains about represented_profile being missing, replaced with a null. To be honest I'm worried about what kind of bug might be breaking things so subtly on the server side, but well, it's not my job. This will result in some friends with missing represented_profile not being included in the contact list, because we're missing rather essential information. But better than not being able to log in.
* fb_http_urlcmp: more loose comparison, to avoid showing urls twicedequis2016-06-02-0/+4
| | | | | Now it returns true if url1 is contained inside url2, or the other way around. This helps when a message body is compared with a url.
* Added support for the new bitlbee plugin informationdequis2016-06-02-0/+21
| | | | See bitlbee/bitlbee@d28fe1c.
* Prevent disconnections on 509 errors, "Invalid attachment id"dequis2016-06-02-2/+13
| | | | | | | | | I'm still not sure about the origin of these errors (I suspect it's a race condition between servers), but it's going to be fixed properly in the future when the sync protocol is updated and doing HTTP requests to get the attachment URL is no longer required (newer orca versions only do HTTP requests to get the url of file attachments, everything else is included in the MQTT stream)
* Make $.hugePictureUrl.uri optionaldequis2016-06-02-22/+27
| | | | | | | | Facebook seems to randomly send null in this field sometimes. It's not very important so it can be made optional. This includes moving the checksum code (which was previously duplicated) to a separate function so that there's a single null check.
* Store sent message id in lastmid, to deduplicate echoed messagesdequis2016-05-16-0/+1
| | | | | | | | | | | Mostly fixes bug #76 This is crappy and error prone, just like the rest of the duplicate message handling code. It works, but it's going to get some echoes now and then, particularly in quick moving groupchats. I'm pretty sure this is a bug in the server, but the official clients have much more elaborate deduplication built-in, so they won't notice.
* mqtt: Fix double free on ssl handshake failuresdequis2016-05-09-0/+3
| | | | | | | | | | | | | Normally, bitlbee's ssl_handshake calls the callback with an error status and calls ssl_disconnect(). In this plugin fb_mqtt_error(), calls fb_mqtt_close(), which called ssl_disconnect() on priv->ssl. This fix prevents that double ssl_disconnect() by setting priv->ssl to null, so that fb_mqtt_close() cleans everything except that. Fixes #82
* Consistency changes for 69b90b5jgeboski2016-03-29-41/+44
|
* Mark as read on reply, mark as read only when availableMarius Halden2016-03-29-7/+85
| | | | | | | | | | The set `mark_read` now accepts `available` in addition to `true` and `false`. When `mark_read` is set to `available` it will only mark messages read when the user is not marked as away/invisible. The set `mark_read_reply` was added, when this is set to `true` any unread messages will be marked as read when the user replies them (assuming they where received by bitlbee).
* facebook-api: fix contacts pagination, use page_info.end_cursordequis2016-03-29-18/+15
| | | | | | This fixes contact list fetching for accounts with more than 500 friends, which only got the first page of results. The previous method, using graph_api_write_id, stopped working at some point.
* Properly initialize the bee_user datajgeboski2016-03-10-2/+16
| | | | | This is mainly for sanity and consistency as the bee_user should be zeroed.
* facebook-api: use the icon URL as a backup checksumjgeboski2016-01-16-2/+13
| | | | | | | There is a report of the 'oh' parameter missing from some of the icon images, which is used as the checksum. The solution is to simply use the URL itself as the checksum in the *rare* case the 'oh' parameter is missing.
* Updated copyright dates for 2016jgeboski2016-01-15-17/+17
|
* Refactored the fbchats printingjgeboski2016-01-14-25/+14
|
* Unbreak gtk-docJorge Villaseñor2016-01-14-1/+1
| | | | It happens that < and > are special characters for gtk-doc.
* facebook-api: fixed incorrect handling of unknown XMA typesjgeboski2016-01-09-2/+2
| | | | | | This fixes an improper GError propagation, which not is only incorrect, but also has no effect. This ends up leading to the unsupported XMA message being ignored without any notice to the user.
* facebook-api: ignore messages which are sequentially duplicatedjgeboski2016-01-07-5/+17
| | | | | | | | | | | | | | | Sometimes Facebook will sent a batch of duplicated messages over the MQTT stream. There are occasions where Facebook will send duplicated messages which are not sequential, however, it does not occur at the rete of the sequential duplication. This is likely due to the fact that the plugin is using an older revision of the Messenger protocol. For now, we should attempt to ignore sequential duplicates from being from being display. This fix is not bullet proof, but it is simple, and should cut down on the duplicated message spam. The proper fix is likely going to be to update the plugin to use a more recent Messenger protocol revision.
* facebook-api: migrated key mappings to the GTK-Docjgeboski2016-01-04-82/+76
|
* facebook-api: attempt to silently reconnect the MQTT streamjgeboski2016-01-04-1/+15
| | | | | | | | | | | | | | Often times, the MQTT stream is disconnected by Facebook for whatever reason. The only thing I can think of is some sort of load balancing on Facebook's end. It has also been reported that when a user logs out on the Facebook website, their MQTT connections are killed. Whenever the connection is killed by Facebook, the user is able to reconnect right after. In order to make for a quieter experience, the plugin should attempt to silently reconnect before notifying the user of an error. This is done by relying on the sequence identifier and the message queue to ensure everything remains synchronized for when the connection returns.
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-26 16:06:05 +0000