| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Those URLs seem to be generated when the Android share feature is used.
Fixes #97
|
|
|
|
| |
And add the FetchContactsDeltaQuery one.
|
|
|
|
| |
Shot in the dark to fix checkpoint issues, but had to be done anyway.
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
| |
It happens that < and > are special characters for gtk-doc.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 namely for the RedHat guys maintaining RHEL 6.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This reverts 68c46dd. While the sending queue attempted to ensure each
message was sent in order, it also lead to a significant delay in the
sending of messages. This is due in part to Facebook taking upwards of
a minute or more to reply to a message being sent. Moreover, the queue
is not really needed unless messages are being spammed.
|
|
|
|
|
| |
This enables various format string security checks by the compiler in
attempt to avoid run-time failures.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|