| Commit message (Collapse) | Author | Age | Lines |
|---|
| |\ |
|
| | |
| |
| |
| | |
Showed up in debian builds
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This handles the most common error case with an obvious error message
(channel already exists, join it, etc), and the rarer ones with vague
but different wording. For those cases:
- "Could not add chatroom."
This wording is not present in this version anymore, likely means the
channel already exists.
- "Error creating channel for chatroom."
irc_channel_new() failed but the channel doesn't exist already. This
could be that some name validation failed, but this function already
generates a suitable name.
- "Error adding chatroom."
irc_channel_new() succeeded, but one of the set_setstr() failed. There
are account checks earlier, and the room setting is not normally
validated at this point.
Can't really imagine situations where these vague errors would still
show up, but at least now you only get those for unknown cases.
|
| | |
| |
| |
| |
| | |
The change in root_commands.c is due to -Wformat-zero-length, which is
bs but whatever. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47901
|
| |\| |
|
| | | |
|
| | |
| |
| |
| | |
It was 16 before.
|
| |\| |
|
| | |
| |
| |
| |
| | |
There's a functionality change buried here, but it's one that people
shouldn't be using anyway.
|
| |\| |
|
| | | |
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Turns out he already implemented pretty much the same thing in the
parson branch... last year.
The differences between the two approaches are subtle (there aren't too
many ways to do this, some lines are the exact same thing) but I decided
I like his version better, so this mostly reverts a handful of my
changes while keeping others. The main advantage of his approach is that
no fake protocols are registered, no actual prpl functions are called,
and the missing prpl is a singleton constant.
New things compared to the implementation in the other branch:
- The explain_unknown_protocol() function.
- Fixed named chatrooms throwing a warning and losing the "account"
setting when saving. See changes in irc_im.c
- Fixed the "server" setting dropping when saving. See account.c
Differences with my previous implementation:
- Accounts with missing protocols don't autoconnect
- 'account list' marks them as "(missing!)"
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of failing to load the config, a fake prpl is created to load
the account, keep its settings, and refuse to log in with a helpful
error message.
Also added a new explain_unknown_protocol() function which returns text
which attempts to explain why a protocol is missing, handling several
typical cases, including the future removal of several dead libpurple
plugins.
That message is shown when logging in to a loaded account with a missing
protocol and when adding a new one with 'account add', with the
difference that the latter doesn't leave a placeholder fake account.
|
| |\| |
|
| | |
| |
| |
| |
| |
| | |
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}
|
| | | |
|
| |\| |
|
| | |
| |
| |
| | |
By using the str_pad_and_truncate() function I just added
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Several protocols can provide a list of existing chatrooms that a user
is able join. This is crucial for the usage of several protocols, most
notably Purple and Facebook.
Plugins wishing to support this extended functionality must implement
the new prpl->chat_list() function. This implemented function will in
most cases send a remote request for the list of chatrooms. Once the
list of chatrooms is obtained, a bee_chat_info_t GSList must be created
and assigned to the im_connection->chatlist field. Then a call to the
bee_chat_list_finish() is needed to display the list to the user.
The chat list is maintained entirely by the plugin, so it is important
to ensure all pointers related to the chat list remain valid until the
chat list is set to NULL. This list is used internally by bitlbee to
calculate indexes, which then allows the user to join a chat with an
index, rather than some random identifier. It also important to ensure
the list is properly freed whenever it is updated, or when the account
is disconnect via the prpl->logout() function.
On the user interface side of things, the 'chat list' subcommand was
recommissioned. For a user to list the existing chat rooms:
chat list <account id>
Afterwards a user can join a chatroom in the list with its index. This
extends the functionality of the 'chat add' subcommand by adding in
support for the exclamation point operator to denote an index.
chat add <account id> !<index> [channel]
|
| | | |
|
| | | |
|
| | | |
|
| |\ \ |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Several protocols can provide a list of existing chatrooms that a user
is able join. This is crucial for the usage of several protocols, most
notably Purple and Facebook.
Plugins wishing to support this extended functionality must implement
the new prpl->chat_list() function. This implemented function will in
most cases send a remote request for the list of chatrooms. Once the
list of chatrooms is obtained, a bee_chat_info_t GSList must be created
and assigned to the im_connection->chatlist field. Then a call to the
bee_chat_list_finish() is needed to display the list to the user.
The chat list is maintained entirely by the plugin, so it is important
to ensure all pointers related to the chat list remain valid until the
chat list is set to NULL. This list is used internally by bitlbee to
calculate indexes, which then allows the user to join a chat with an
index, rather than some random identifier. It also important to ensure
the list is properly freed whenever it is updated, or when the account
is disconnect via the prpl->logout() function.
On the user interface side of things, the 'chat list' subcommand was
recommissioned. For a user to list the existing chat rooms:
chat list <account id>
Afterwards a user can join a chatroom in the list with its index. This
extends the functionality of the 'chat add' subcommand by adding in
support for the exclamation point operator to denote an index.
chat add <account id> !<index> [channel]
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Several protocols can provide a list of existing chatrooms that a user
is able join. This is crucial for the usage of several protocols, most
notably Purple and Facebook.
Plugins wishing to support this extended functionality must implement
the new prpl->chat_list() function. This implemented function will in
most cases send a remote request for the list of chatrooms. Once the
list of chatrooms is obtained, a bee_chat_info_t GSList must be created
and assigned to the im_connection->chatlist field. Then a call to the
bee_chat_list_finish() is needed to display the list to the user.
The chat list is maintained entirely by the plugin, so it is important
to ensure all pointers related to the chat list remain valid until the
chat list is set to NULL. This list is used internally by bitlbee to
calculate indexes, which then allows the user to join a chat with an
index, rather than some random identifier. It also important to ensure
the list is properly freed whenever it is updated, or when the account
is disconnect via the prpl->logout() function.
On the user interface side of things, the 'chat list' subcommand was
recommissioned. For a user to list the existing chat rooms:
chat list <account id>
Afterwards a user can join a chatroom in the list with its index. This
extends the functionality of the 'chat add' subcommand by adding in
support for the exclamation point operator to denote an index.
chat add <account id> !<index> [channel]
|
| | |
| |
| |
| | |
This reverts commit 659df4e333f2f524350dd131e430faaeb66dd91a.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Several protocols can provide a list of existing chatrooms that a user
is able join. This is crucial for the usage of several protocols, most
notably Purple and Facebook.
Plugins wishing to support this extended functionality must implement
the new prpl->chat_list() function. This implemented function will in
most cases send a remote request for the list of chatrooms. Once the
list of chatrooms is obtained, a bee_chat_info_t GSList must be created
and assigned to the im_connection->chatlist field. Then a call to the
bee_chat_list_finish() is needed to display the list to the user.
The chat list is maintained entirely by the plugin, so it is important
to ensure all pointers related to the chat list remain valid until the
chat list is set to NULL. This list is used internally by bitlbee to
calculate indexes, which then allows the user to join a chat with an
index, rather than some random identifier. It also important to ensure
the list is properly freed whenever it is updated, or when the account
is disconnect via the prpl->logout() function.
On the user interface side of things, the 'chat list' subcommand was
recommissioned. For a user to list the existing chat rooms:
chat list <account id>
Afterwards a user can join a chatroom in the list with its index. This
extends the functionality of the 'chat add' subcommand by adding in
support for the exclamation point operator to denote an index.
chat add <account id> !<index> [channel]
|
| |\| |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As of now, bitlbee will load any plugin regardless of the ABI it was
built against. This is really problematic when structures or symbols
are changed within bitlbee. This often leads to the plugin not loading
or the plugin acting in an undefined way. Typically a simple rebuild of
the plugin will resolve such issues, but many users have no idea that
this is required after they have updated bitlbee.
Furthermore, it is often times impossible to determine the version of
a plugin, without relying on the package manager of the system. This is
quite a problem when users are reporting bugs for external plugins, and
they have no idea what version of the plugin they are running. This is
also an opportunity to provide additional metadata for each plugin that
can then be displayed to the user.
Solving these issues is done by adding a new required function to each
plugin. The init_plugin_info() function must now be implemented along
with the init_plugin() function. This function then returns a static
structure, which retains all of the metadata for the plugin. Then this
is used by bitlbee to check the ABI version and provide information to
the user.
The introduction of the new function is required as bitlbee needs to
obtain the ABI version before calling init_plugin().
The boiler-plate implementation of init_plugin_info():
#ifdef BITLBEE_ABI_VERSION_CODE
struct plugin_info *init_plugin_info(void)
{
static struct plugin_info info = {
BITLBEE_ABI_VERSION_CODE, /* Required */
"plugin-name", /* Required */
"1.3.3.7", /* Required */
"A short description of the plugin", /* Optional */
"First Last <alias@domain.tld>", /* Optional */
"http://www.domain.tld" /* Optional */
};
return &info;
}
#endif
The example wraps the function declaration in an if block for backwards
compatibility with older bitlbee versions.
Displaying the plugin metadata is done via the newly added "plugins"
command, which simply dumps formatted data to the root channel.
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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".
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This adds the disabled protocols' prpl structs to a different linked
list, only used for this lookup. They were previously marked as leaking
by valgrind, so, whatever. I can't free them, since some protocols
memdup() it after attempting to register.
I think disabling the protocols from bitlbee.conf is just stupid and
provides no real benefits, but someone will complain if i get rid of it.
So this just improves the error message to make it less confusing when
someone accidentally uncomments that crap.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Only plain, no other methods. We don't have built-in SSL to implement
EXTERNAL (certfp) and nothing else is worth implementing.
The actual authentication is pretty much like sending a server password
(when the server's authmode isn't closed), which means it happens in
cmd_identify, but this code also calls storage_check_pass() to send the
required success/failure replies.
SASL doesn't give us much benefit other than standards compliance, but
some clients might appreciate it.
And having a fifth way to do the same thing doesn't hurt! Now we have:
- identify in &bitlbee
- identify to nickserv (alias for root)
- 'nickserv' and 'ns' irc commands
- server password
- sasl plain
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Add an (optional) second parameter to blist. If present, it is treated
as regex and used to filter the result list.
|
| |
|
|
| |
Only took me a few months to write. I even added a test case.
|
| |
|
|
|
| |
"securely". Patch from Flexo, bug #1117.
|
| | |
|
| |\
| |
| |
| |
| |
| | |
XML-formatted user configs from disk I/O so we can try to start using other
mechanisms to store them (a REST API or something, for example).
|
