| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
| |
I have no idea what request after login requires api keys, though.
This plugin signs all post-login requests pointlessly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
>Login error: Failed to read thrift: facebook-api.c:1815
>fb_api_cb_publish_pt: assertion 'FALSE' failed
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Last commit was broken
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
|
| | |
|
| | |
|
| |
|
|
| |
The server expects the tid parameter to be just the tid now.
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
| |
Those URLs seem to be generated when the Android share feature is used.
Fixes #97
|
| | |
|
| |
|
|
|
|
| |
Because apparently that's a thing that happens (incoming delta with
added item saying "friendship_status": "CAN_REQUEST" instead of
"ARE_FRIENDS")
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
| |
And add the FetchContactsDeltaQuery one.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Those are created by the "Marketplace" feature:
http://newsroom.fb.com/news/2016/10/introducing-marketplace
|
| |
|
|
| |
Shot in the dark to fix checkpoint issues, but had to be done anyway.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
This ensures a message is sent successfully before attempting to send
another message. As a result, messages are sent in their proper order,
instead of the order in which they arrive. This also introduces a check
for the successful sending of a message, rather than silently failing.
The queued sending also ensures messages are not lost when the state of
visibility is being switched. This also allows the plugin to silently
reconnect when a connection failure occurs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The plugin is required to read Thrift data for the presence states of
contacts. The data which is being read has some optional fields, which
are rarely not supplied. This has led to this bug being undiscovered
for quite some time.
Not only was the plugin not properly accounting for optional fields,
but also did not account for field scoping. This is not really an issue
until a Thrift list is being read, which will cause the identifier to
grow with each field read, rather than reset. The field identifier is
only relevant to its local scope, nothing more. More importantly, the
identifier must be reset with each iteration of a list.
|
| |
|
|
| |
This is a regression introduced by 00c0ae8.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When fetching more than 500 contacts, multiple requests must be made in
order avoid request limits. When friends are retrieved and processed,
the plugin must keep a count of the processed contacts to know whether
or not it needs to retrieve more contacts.
Currently, this counter assumes every contact is a friend, which is not
always the case. This counter needs to advance even when a contact is
not a friend.
This fixes the incomplete fetching of the buddy list when a user has
over 500 friends.
This is a regression introduced by 00c0ae8.
|
| | |
|
| |
|
|
| |
This regression was introduced by 00c0ae8.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
By not swapping uid with oid, since the latter is always 0.
|
| | |
|
| | |
|
| | |
|
