aboutsummaryrefslogtreecommitdiffstats
path: root/protocols/purple
Commit message (Collapse)AuthorAgeLines
* purple: enable debug during core initializationdequis2017-07-12-1/+3
| | | | Noisy but often important
* Add --verbose configure option to control verbose build outputTim Harder2017-03-12-2/+2
| | | | Defaults to disabled to maintain the status quo.
* purple: Fix crash on ft requests from unknown contactsdequis2017-01-29-0/+4
| | | | | Followup to 701ab81 (included in 3.5) which was a partial fix which only improved things for non-libpurple file transfers (that is, just jabber)
* purple: show self-messages in groupchat backlogs (before join)dequis2017-01-03-3/+7
| | | | | | That is, flagged with PURPLE_MESSAGE_DELAYED. Those are safe to display. This is similar to what adium does. Thanks EionRobb for the idea.
* purple: fix -Werror=format-string in chat settings codedequis2016-12-26-4/+2
| | | | | This one was caught by the debian build scripts in travis. I had format-security in my local cflags, not format-string. Welp.
* purple: hack to keep the purple-line auth token in the configdequis2016-12-26-1/+20
|
* purple: add support for extra groupchat settings (helps with SIPE)dequis2016-12-26-0/+93
| | | | | | | | | | | | | | | | | This adds channel settings prefixed by purple_. For example jabber now has purple_room and purple_server which are decomposed variants of our own 'room' setting. Okay, that doesn't sound very useful. It also adds some sync from the values returned by chat_info_defaults() - so if the plugin figures something out in there, we save it in our own settings. In the case of SIPE this adds a new setting, purple_uri, which can be set with the ma-chan:// uri for a persistent chat. This solves the issue with the SIPE plugin only knowing how to do name lookups after doing 'chat list' - now it just needs to work once, and we save the real URI in our settings.
* Change some asserts into g_return_if_fail()dequis2016-12-26-2/+2
| | | | | | Because crashing asserts are bad, and maybe this helps fix the captures_build_path issue with debian's reproducible builds (those asserts probably include __FILE__)
* purple: Call imcb_buddy_nick_change() on a few whitelisted pluginsdequis2016-12-25-4/+40
| | | | | | | | The whitelist includes hangouts, funyahoo and icq. These plugins tend to have numeric or meaningless usernames. With this change, users don't have to do 'ac whatever set nick_format %full_name' anymore. Just sugar.
* purple: include purple plugins in the 'plugins' command listdequis2016-12-25-0/+15
|
* purple: Use roomlist_room_serialize, fixes joining jabber chatsdequis2016-11-28-3/+17
| | | | | | | The room names in 'chat list' were missing the server part. Jabber is the only prpl which implements this method as far as I can see, and it's needed to get the full name.
* Improve support for protocols which don't require a passworddequis2016-11-13-0/+10
| | | | | | This adds a prpl_options_t enum with flags, which mostly just brings OPT_PROTO_{NO_PASSWORD,PASSWORD_OPTIONAL} from libpurple as PRPL_OPT_{NO_PASSWORD,PASSWORD_OPTIONAL}
* purple: fix file transfer memory managementdequis2016-11-13-11/+75
| | | | | | | | | | | | | | | | This means cancelling transfers on logout to avoid crashes, keeping track of timeouts, reffing and unreffing the xfers, listening to the callbacks from UI and purple more carefully and using the correct functions to free the correct things at the correct moments. Originally intended to fix a crash triggered when the dcc stall timeout kicks in after the account is offline, which is apparently very frequent with telegram (it sends file transfers while fetching history, and randomly disconnects a while later). Trying to fix that meant opening a can of worms, but after three days of work on this bug I'm pretty sure I've finished dealing with the resulting mess and tested all the typical edge cases.
* purple: hack to pass server parameter to jabber's input requestdequis2016-11-04-2/+23
| | | | | | | | | | | | Because our purple module is all about hacks, adding more can't hurt. There's a string comparison for "Enter a Conference Server". It's gettexted in the source but in practice it isn't affected by locale (bitlbee disables localization). Worst case, if this stops working, it will open an input request like it did before this commit. It also does that in purple's jabber if you don't provide a server parameter.
* purple: fix icq login when the protocol name is "oscar"dequis2016-10-30-4/+17
| | | | | | | | | | | | | | | Which happens when moving from non-purple to purple. Fixes trac ticket 1269 Since "oscar" doesn't exist in purple, the old code called register_protocol() to associate oscar with prpl-aim, which meant that aim accounts migrated seamlessly to purple but icq accounts broke silently, throwing incorrect password errors. Now the oscar protocol is special-cased to return prpl-aim or prpl-icq depending on the first character of the username, which is the same thing the built-in oscar protocol does.
* Turn purple_chatlist_free() into a imcb_chat_list_free()dequis2016-10-16-17/+2
| | | | | I found myself copypasting this to jabber. Might as well make it part of the API.
* Rename bee_chat_list_finish() to imcb_chat_list_finish()dequis2016-10-16-1/+1
| | | | | | | | | bee_chat_list_finish is still available as a deprecated function but it will be removed before the next stable release It has never been part of any release, just keeping it for a while for the sake of being polite to the users of the discord plugin who may be using the experimental chat list branch.
* purple: Fix handling of empty, immediate roomlist resultsdequis2016-10-08-10/+22
| | | | | | | | | | | | | | | | | | | | Two issues here: 1. SIPE called in_progress(FALSE) immediately (which decreases refcount), before purple_roomlist_get_list() could return (which would normally increase refcount). The first refcount decrease steals it from the prpl, and bad things happen. Added an initialized flag to only do that decrease after it was increased first. This is similar to how pidgin sets a 'dialog' attribute after the purple_roomlist_get_list() call, and skips the unref if it's not set. 2. The code assumed that NULL return value means room listing not supported. That's not quite true, so now it checks in the prpl info to see if roomlist_get_list is defined. Also, made purple_roomlist_data more private.
* purple: Fix another issue where /join results in two channelsdequis2016-09-25-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Follow up to a3019499665384a3dcbbc11016d256e6d4dcd26c (which actually made things worse than before for this particular case - found it by bisecting) This affected skypeweb and hangouts, maybe others. Sometimes serv_join_chat() results in a call chain like this (outermost frame first) 1. purple_chat_join 2. serv_join_chat 3. (the join_chat function of the prpl) 4. serv_got_joined_chat 5. purple_conversation_new 6. prplcb_conv_new The last one tries to find a struct groupchat by name (that's the code from the referenced commit). If it doesn't exist, it creates a new one. This usually isn't an issue because the 4th step is done asynchronously, and a groupchat is created at the end of purple_chat_join. If it's not, you end up with two groupchats, which can lead to other nasty issues. This moves the creation of the groupchat right before serv_join_chat(). That way, it always exists even if the conversation is created immediately.
* purple: support setting chat room topics (#84)Eion Robb2016-09-24-0/+16
|
* purple: added room listing supportjgeboski2016-09-19-0/+134
|
* purple: Don't try to init module if it's already initializeddequis2016-07-25-0/+6
| | | | | This only happens if the user has used / forced daemon mode (for example, when debugging with BITLBEE_DEBUG=1)
* purple: add $plugindir/purple to the plugin search pathdequis2016-06-12-0/+4
| | | | | | | | | | | | | | This allows adding bitlbee-specific purple plugins in a directory controlled by the user who starts bitlbee (as it can be defined in bitlbee.conf, PluginDir). Pidgin and finch have something similar allowing users to place plugins in ~/.purple/plugins: path = g_build_filename(purple_user_dir(), "plugins", NULL); The direct equivalent would be to use our config dir, but i'd rather not put executable modules there.
* purple: strdup the message instead of casting to char *dequis2016-05-25-3/+6
| | | | | | Fixes trac ticket 1255, which points out that a strip_html() call down there may modify the passed string, and some purple plugins may pass read-only string data to it.
* purple: Also show 'title' and 'primary' messages for input requestsdequis2016-01-21-1/+12
| | | | It was showing 'secondary' only before.
* purple: Show self-messages for private messages onlydequis2015-12-27-24/+25
| | | | | | | | | | Those are purple_conversation_write with PURPLE_MESSAGE_SEND flag set, received through the write_conv UI op. write_chat and write_im still receive and filter PURPLE_MESSAGE_SEND. In the case of write_chat it *could* show some of those, but it seems there's no decent way to tell echoes apart from remote self-messages. So just keep those hidden for now.
* purple: document original names of uiops next to themdequis2015-12-26-64/+64
|
* purple: fix crash when doing 'chat with' with skypewebdequis2015-12-06-1/+1
| | | | | | | | | | | It was passing the wrong data to the callback - it was supposed to pass the data of the PurpleMenuItem but it passed the PurpleMenuItem itself. Probably also applies to other protocols too. It worked fine with jabber, which i'm guessing is what this code was tested with originally. It still whines about the null return value saying "(Possible) failure" but, eh, whatever.
* purple: assume HTML for all protocols, fixes random <> for somedequis2015-12-01-3/+1
| | | | | | | | Purple's IRC, for example, doesn't have the PURPLE_CONNECTION_HTML flag, but still sends html for format codes. Note that using IRC through libpurple through bitlbee is still a terrible idea. Use ZNC instead.
* purple: Implement PurpleNotifyUiOps.notify_messagedequis2015-12-01-1/+22
| | | | | | | | | | | | | | | | | | Which has no connection context. Luckily local_bee exists, and libpurple only supports only one irc user per process. This sucks. And yesterday I was naively thinking (again) that local_bee might not be needed, that maybe we can do things properly. Of course it only took a look at that one reverted commit (56985aa) to remember that life is unfair, and that, under Moloch, everyone is irresistably incentivized to ignore the things that unite us in favor of forever picking at the things that divide us in exactly the way that is most likely to make them more divisive. That being said, I think all these hacks are going to look nicer once I sandbox the whole thing in a separate process with one IM account per process, as opposed to one irc use per process. Then we'll be able to rely on global state exclusively, which is saner.
* purple/ft: remove prplcb_xfer_dbg entries with mismatching signaturesdequis2015-12-01-7/+2
| | | | More fixing warnings.
* purple: avoid warnings in the PURPLE_INPUT_* enum checksdequis2015-11-30-5/+2
| | | | Also turn them into asserts because that's what it really does.
* purple: fix a bunch of small leaksdequis2015-11-25-0/+11
| | | | | Most of them related to channel joins, one of them related to my recent certificate pool path fix.
* purple: fix /join #channel, which joined a different channeldequis2015-11-25-4/+12
| | | | | | | | | | | | | | | | | | | | When joining named channels, purple_chat_join() returned NULL instead of a struct groupchat, which was actually created in the conversation created callback (prplcb_conv_new()). If the name of this channel turned out to be different to the joined one, this meant having one empty window in the irc client, and another one for the other channel. The fix is to return a mostly-empty struct groupchat immediately, and pick it up later when the PurpleConversation is created using bee_chat_by_title(). If that fails, fall back to creating a new one. This bug also meant there was no proper way to report a join failure. Future commits will address that, this one just makes that easier. Thanks to Etan Reisner (deryni) for enlightening me while i was trying to figure out how to fix this.
* purple: Fix certificate cache dir after changing user dirdequis2015-10-25-0/+6
| | | | | | | | | | | | | | | | This fixes the issue with getting asked to accept certificates that are perfectly valid, every time. The directory is normally created by x509_tls_peers_init(), a few calls below purple_core_init(), which is at module initialization time, way before we have an irc username to fix the user directory. So it creates the wrong directory first, and now we have to fix it manually. And apparently not being able to save cached certificates somehow means they aren't trusted. For some reason. < krisfremen> "for some reason" < dx> idklol
* socks4a proxy support (like socks4 with remote DNS)dequis2015-10-21-0/+7
| | | | | | | | | Fixes trac ticket 995 https://bugs.bitlbee.org/bitlbee/ticket/995 This is slightly pointless for the suggested use case (tor), since with socks5 we already send a hostname instead of an IP address. Either way, it was easy to implement, so I hope it helps.
* Rename mail notification related settings for consistencydequis2015-05-28-3/+3
| | | | | - GMail notifications stuff is now just 'mail_notifications' - sed -i s/notify_handle/mail_notifications_handle/
* imcb_notify_email: change parameters to take a format stringdequis2015-05-28-3/+1
| | | | | | | Saves some messing with g_strdup_printf for the callers, and flags/sent_at weren't used anyway. Also check if the mail_notifications setting is enabled
* Gmail notifications support through new imcb_notify_email() APIArtem Savkov2015-05-28-1/+10
|
* purple: Fix null pointer dereference when logging out due to daemon modedequis2015-03-15-0/+4
| | | | | Purple just doesn't work with daemon mode anyway, but it's better to show the intended error message than to crash while showing it.
* purple: prplcb_close_request() improvementsdequis2015-03-15-24/+53
| | | | | | | - Added support for PURPLE_REQUEST_INPUT - Changed memory management to do the free() of data through purple_request_close(), letting purple know that the request was answered, and fixing use-after-free issues with it
* purple: handle purple_request_inputAntoine Pietri2015-03-13-1/+66
|
* purple: Implement 'close_request' to prevent segfaults after logoutdequis2015-03-11-1/+14
| | | | | | | | | | | | | | | Fixes trac bug 1190 ("Accepting SSL certs too late resets bitlbee-libpurple") To reproduce: 1. Connect to server with self-signed ssl certificate (downgrading to libpurple 2.10.9 might be required to actually get the request) 2. Disconnect the account 3. Type "yes" 4. Acquire segfault. Normally, query_del_by_conn() would handle this, but some requests have no account context at all. Yeah, it sucks. This is how pidgin handles it.
* Revert "purple: cleanup, remove one usage of static local_bee"dequis2015-03-03-2/+1
| | | | | | | | | | | This reverts commit 5ff46180e5378acd6d103d9314175c78530bda7e. Turns out that libpurple really doesn't provide any context at all for some queries. Also, not going to say "Shouldn't affect anything" again. I'm getting good at writing code that looks good, but actually breaks stuff. That's not good. At all.
* purple: move PurpleAccount from proto_data in a struct purple_dataAntoine Pietri2015-03-02-47/+78
|
* purple: cleanup, remove one usage of static local_beedequis2015-02-22-1/+2
| | | | | Shouldn't affect anything, and still doesn't allow initializing libpurple more than once, but whatever.
* Reindent everything to K&R style with tabsIndent2015-02-20-939/+929
| | | | | | | Used uncrustify, with the configuration file in ./doc/uncrustify.cfg Commit author set to "Indent <please@skip.me>" so that it's easier to skip while doing git blame.
* purple: Implement /kickdequis2015-01-30-0/+9
|
* purple: add NULL guard around topic and name hintAntoine Pietri2015-01-26-2/+5
|
* purple: add topic and name_hint to groupchatsAntoine Pietri2015-01-25-0/+3
|
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-27 21:53:07 +0000