Starting with glib 2.69 g_match_info_fetch() returns an empty string
instead of NULL in case when no match was found. Properly handle this
case.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
As mentioned in #226 there is some issue with newer glib versions. Add
the dump of our request for websocket upgrade to see if that'll make
things clearer.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
No configuration, no proper parsing of the replied to message, nothing.
This is a quick and dirty implementation for replies. On reply this will
display the first 50 characters of the replied to message along with
original authors name and hardcoded IN_REPLY_TO prefix.
Fixes: #215
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Turns out opcode 13 is responsible for syncing private group DMs. Ask
for that on join. Don't have any way to check it currently, just hoping
it will return a familiar message.
Discord no longer seems to support per-guild sync, but per-channel sync
was added. Switch to that syncing user lists on channel join.
Fixes: #201
Signed-off-by: Artem Savkov <artem.savkov@gmail.com>
For whatever reason discord stopped responding to REQUEST_SYNC
opcode(12) so we timeout on login. Temporary ignore the issue and assume
we have completed connections even though we are missing guild info.
I am no longer sure of the full list of effects this will have, we will
surely lose guild presence info.
This is a workaround for #201 and should be reverted once that is
properly fixed.
Signed-off-by: Artem Savkov <artem.savkov@gmail.com>
Send every message with a unique nonce saving and saving it in a
hashtable making sure we don't echo back our own messages.
Commit is based on a patch contributed by Trecourt Nicolas, thank you!
Fixes: #182
Print-out whatever we read from ssl on failure to switch to websocket so
we can tell what is going on. This is mainly here to help debug #180 but
should be useful in future as well.
I think this is caused by uinf and uinf->user being a null pointer. Not really sure why that is, but this fixes the crash that would otherwise cause. I imagine it's because the user has never actually existed within the bitlbee user list and therefore doesn't need updating, but the real question is why it works for the first rejection but not the second.
I also slightly cleaned it up so uinf is defined before usage in either case, meaning there's only one definition statement.
Before these fixes, RELATIONSHIP_REMOVE would cause a segfault. My understanding of this, is that RELATIONSHIP_REMOVE's json looks like: {"t":"RELATIONSHIP_REMOVE","s":97,"op":0,"d":{"type":1,"id":"<removed>"}} and this is the primary cause of this problem.
In the original code, json_value *uinfo = json_o_get(rinfo, "user"); would lead to a null pointer being fed into discord_canonize_name as char *name = discord_canonize_name(json_o_str(uinfo, "username")); has no handling for being fed a null pointer.
Instead of adding in specific null pointer handling, I reworked it to get the ID from the request and to use get_user to get the user from that, instead.
This helps avoid wasted time in the other Discord client looking for which message is missing - especially in the case where the HTTP server reports failure, but the message actually arrived.
Starting with 98f3893 we support multiple awat statuses, that commit
changed the default away status to "online", resulting in commands like
'/away food' working the same way as 'set status food', i.e. leaving the
person in online state, but with a message set.
Change the default away status to 'idle' as it worked previously, this
should fix#161.
Add an option to always report client's status as afk, this will
hopefuly force push notifications to be delivered to other clients when
bitlbee is connected. See #131 for more info.
This makes sure nobody else runs into traps involving 'unix', 'linux' and a few others being predefineds macro, and it improves compatibility with old compilers that default to -std=gnu89 and fail on variable declarations in for loops. (Modern GCCs default to -std=gnu11.)
Fixes#156
Discord sends message times which are useful in case of pinned/backlog messages, relay those to bitlbee so that it can timestamp messages like this.
Fixes: #152
Recognize 'captcha-required' discord error instead of printing null
error message. Also add info on how to get the token and a link to
original issue to README.
Enclose emoji URLs in brackets.
Discord allows emoji to be sent back to back without any delimiters resulting in botched urls. Add <> brackets so that emoji urls are separated from the rest of the text.
With soft reconnects it is now possible for bitlbee to request status
change in the middle of reconnect causing a write to uninitialized ssl
socket and consequent segfault.
Postpone setting status until we are in a WS_READY state.
Discord's docs specify that heartbeat ack should be received between
heartbeats, so adjust this to just under keepalive_interval.
I don't expect it to trigger often (or at all). Based on what I saw so
far we are much more likely to get some sort of websocket error before
this triggers.
In WS_READY state (after we got server info) it should be safe to do a
soft-reconnect on any of the websocket errors instead of full relogin.
This should improve relogin situation quite a bit since these are
causing the most reconnections.
All of the possible websocket read errors previosly just resulted in a
"Failed to read data" error making it imposible to determine which part
failed. Rephrased those errors.