| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
|
| |
Add support for tagged messages by adding the functions
irc_send_tagged_msg*, the old irc_send_msg* functions are now wrappers
for these functions without any tags.
|
| |
|
|
|
|
|
|
| |
We only support the openldap scheme for now, with users that are
posixAccounts. Moreover, as the plugin cannot be configured directly,
you must configure libldap correctly in /etc/openldap/ldap.conf
|
|
|
|
| |
This backend authenticates users against pam.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of always putting users passwords in XML files, allow site
admins to configure a different authentication method to integrate
authentication with other systems.
This doesn't add any authentication backends yet, merely the
scaffolding. Notably:
- Password checking and loading/removing from storage has been
decoupled. A new auth_check_pass function is used to check passwords.
It does check against the configured storage first, but will handle
the authentication backends as well. The XML storage merely signals
that a user's password should be checked using an authentication
backend.
- If unknown-to-bitlbee users identify using an authentication backend,
they are automatically registered.
- If an authentication backend is used, that fact is stored in the XML
file, the password is not. Passwords are also stored unencrypted in
this case, as the password used to encrypt them can change underneath
us.
- configure and Makefile changes for the backend objects
|
|
|
|
|
| |
In a locked down bitlbee instance it is useful to disable the 'account
add' command.
|
|
|
|
|
|
| |
This allows a site admin who pregenerates configs to mark certain
settings as untouchable, ensuring that users cannot mess up their
settings too badly.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In certain situations, e.g. when working with pregenerated
configurations, it is useful to be able lock down accounts so they
cannot be deleted and authentication information (user, password,
server) cannot be changed.
We mark such sensitive settings with ACC_SET_LOCKABLE and will refuse to
change them if the account is locked by setting the ACC_FLAG_LOCKED
flag.
This flag is stored in the xml files as account attribute locked="true".
|
|
|
|
| |
lol
|
|
|
|
|
|
|
|
| |
Send new away message when away-notify is enabled and the status
changes (e.g. "Away" to "Mobile") or the status message changes
without returning from away.
Fixes IRC clients with away-notify persisting old away messages.
|
|
|
|
| |
It was removed in ba7d16f, but this remained.
|
|
|
|
|
|
|
|
|
| |
Basically the same thing as github PR #55, which fixes trac bug 415,
but this one conditionalized that behavior and uses the API introduced a
few commits ago.
I didn't think too much about the setting name and i'm open to changing
it to anything else
|
| |
|
|
|
|
|
|
| |
Fixes trac ticket 865 ("Make bitlbee send "is away" and such status
messages via &bitlbee channel instead of separate query window"),
except that the solution is to not send them at all.
|
| |
|
|
|
|
|
| |
It only affects irc->user and irc->root, and this was calling it for
everyone.
|
|
|
|
|
|
| |
So if someone has several connections with several clients to a chat,
they won't appear as leaving from the chat until they leave from the
last client.
|
|
|
|
|
|
|
| |
nick_hint only works when creating new users, it's a no-op after the
user is online. This new function takes care of nick changes after that.
It also helps clean up couple of hacks in irc_im.c \o/
|
| |
|
| |
|
| |
|
|
|
|
| |
9456255 made the variable 's' unused but failed to remove it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes trac ticket #1248
proxy_connected() calls phb->func(), then tries to do phb_free() directly
afterwards, but that might have been freed by a proxy_disconnect() call
during the execution of that callback.
This one happened to several different people because some AIM server
broke recently.
This commit fixes it by implementing a phb_connected() function that
removes the PHB from the hash table before calling phb->func(), which
ensures that any proxy_disconnect() calls just close the fd and nothing
else.
|
| |
|
|
|
|
|
|
|
| |
Move irc_send_away_notify below bee_irc_channel_update to delay
sending the updated away-notify status until after any nicks have
joined/quit. Otherwise, some IRC clients will drop the status
messages as they go to nicks that the client doesn't know about.
|
|
|
|
|
|
|
|
| |
When sending WHO reply, check if irc_user is the account user and if
so set away status according to global account away configuration.
Otherwise, reply according to irc_user flags. Fixes global away
status not being shown in IRC clients when WHO polling is enabled.
Fixes: https://bugs.bitlbee.org/ticket/1247
|
|
|
|
|
|
| |
Not a big deal because as far as I can see not much happens between the
g_slist_remove() in dcc_close() and accessing files->next. I'd expect
that pointer to remain null after being freed most of the time.
|
|
|
|
|
|
|
| |
The jabber_buddy used for messages sent from other resources connected
to the same groupchat has a different ext_jid and it's a different
object than jc->me, so doing a string comparison against acc->user is
needed.
|
|
|
|
| |
It was showing 'secondary' only before.
|
|
|
|
|
|
|
| |
This reverts commit d11ccbf6ea94264bde8b0f525c4bbedf50de0174.
After thinking about this long enough I've decided this is a bad idea,
and better wait for the hipchat server to support carbons.
|
| |
|
| |
|
|
|
|
| |
This was needed back in 2010, but now it's not.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
When people build with ./configure --purple=1 --oscar=1, the native
oscar is compiled statically, which should take priority, but sometimes
purple's oscar is used instead and bad things happen, most of it being
due to calling bitlbee's native aim_callhandler instead of the function
with the same name of libpurple's liboscar.so.
|
|
|
|
|
| |
The test suite does this. It's harmless in practice but open() is
declared as nonnull. Thanks to clang's ubsan.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reuses part of the carbons code, but it's not like it at all.
To be able to receive these messages at all, a different cap node
whitelisted by them is required. I could have used one of the official
clients, but let's try to get things done the right way.
This will start working once they make that change in their servers,
right now this is still in their ticket backlog. I'm merging this now
because it's harmless and nice to have as part of the upcoming release.
|
|
|
|
|
| |
This prevents them from being stored or copied to other clients when
carbons are enabled.
|
|
|
|
|
|
| |
imcb_find_buddy is mentioned only in nogaim.h, and is never defined anywhere.
This is misleading for plugin authors, who were probably looking for
(the actually implemented) imcb_buddy_by_handle instead.
|
|
|
|
|
|
|
|
|
| |
This reverts commit ed431c389887080dc4fa45e30d051ce733f4ce57.
I'm going to let this leak. Turns out only purple allocates an empty
list for every time this is called. Other protocols have statics, and
they always return the same thing, can't free those. Whatever. The
purple leak was insignificant, just more scratching of itches.
|
|
|
|
|
|
| |
Coverity says it could be an out of bounds read, but the value is set
internally, so not really. Still, good point about the condition being
wrong.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Easiest part of ircv3.2
|
|
|
|
|
|
|
| |
Because modifying this code was making me REALLY uncomfortable.
This still only allocates memory once. Needing to extend the string
would be a bug in the length checks, but at least that's harmless now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes trac ticket 1175, https://bugs.bitlbee.org/bitlbee/ticket/1175
"Setting away with libpurple fails silently except for a few values"
Turns out the fallback was the first item of the list, which for
libpurple's jabber is "Feeling" (what?) and seems to be a no-op in
practice.
With this commit the fallbacks are in this order:
1. Try to find whatever the user wrote in the away setting.
2. If that fails, find "away" in the away states.
3. If that fails, use the first away state.
This might not fix it in some rare cases where the prpl doesn't have
an away state equivalent to away. But hopefully the old fallback works
for those, jabber was the weird one here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Facebook's oauth has been broken for months, and in the last few days
they broke plain logins too, so I just added an error message that says
this when you do "account on":
Facebook's XMPP service is gone. Try this instead:
https://wiki.bitlbee.org/HowtoFacebookMQTT
Also nuked all the oauth related code, except some parts of lib/oauth2.c
which seemed generic enough to maybe help in the future with other
not-really-compliant not-really-implementations of the not-really-oauth2
not-really-spec
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|