Current lookup would return the wrong user if the intended user has left
the hub and the SID has been re-used. If the CID matches then we assume
the user is still there.
The UCMD specification doesn't mention nested blocks, and LinuxDC++ (and
therefore presumably any other client based off the DC++ core) doesn't
support them. But for future-proofing / clients that do support them,
make sure the ucmd_escape_msg() function can handle nested blocks
properly.
This reverts commit a12e79c7ce. There is
no need to check the plugin API version within the plugin itself as
pluginloader.c does the following check (currently line 133):
(handle->plugin_api_version == PLUGIN_API_VERSION &&
handle->plugin_funcs_size == sizeof(struct plugin_funcs))
Can be filtered to include only users of a certain credential level, or
users of a certain credential level or greater. Results are returned as
a linked list of plugin_user objects.
Hub function to free the memory used by the list also added.
As plugins may store the list, users may disconnect before the list is
used. Hence a copy of each user is made for the list, so that if a
plugin tries to send a message to a user who has left the hub it will be
ignored, rather than the hub trying to access memory that was free()d
when the user disconnected. The lookup function to turn a plugin_user
into a hub_user for some of the other hub functions is changed
accordingly. (I think this description is possibly more confusing than
just looking at the code, but oh well...)
Using adc_msg_escape will escape spaces etc inside keyword subsitutions
in user command messages (e.g., %[line:Enter a value] becomes
%[line:Enter\sa\svalue]) which leads to them being displayed wrong in
the client. Values outside the substitutions still need to be escaped.
This commit adds an (internal) ucmd_msg_escape() function, plus a
ucmd_msg_escape_length() helper, to the user command handler which
correctly handles keyword substitutions.
Adds a mod_ucmd plugin which uses the previously added user command
plugin functions to send user commands when users log in. These are read
from a text file in a simple format. They can be restricted to users
with certain credentials, and can have multiple actions (e.g., send a PM
and a message in the main chat).
A sample user command file for the standard uhub commands is at
doc/ucmd.conf, and will be automatically installed if appropriate.
This currently won't send commands to existing users (e.g., if the
plugin is (re)loaded after the hub is already up and running). To
support this, a plugin function to list all current users would need to
be added.
I'm not sure how efficient this would be due to the volume of
messages needed to delete the existing commands on shutdown and send
them again on startup. As the commands are reloaded properly within the
plugin, it may be easier to require users to reconnect after the
configuration changes (and, of course, an admin could force this by
restarting the hub).
If you have a bot connected to the hub, and you want to add a user
command to interact with the bot via PM, you need to know its session ID
(SID). However, SIDs are assigned when the client first connects, prior
to the nickname being sent, and so we cannot just assign a certain SID
based on the nickname as part of the connection routine.
To overcome this, this commit adds the ability to reserve the first few
SIDs (at hub start time, when the SIDs are known) for certain nicknames.
The user manager then checks each time a user logs in to see if the
nickname matches a reserved one, and if so sets up an alias from the
reserved SID to the SID the user was given. This alias is only checked
for private messages (the ADC DMSG or EMSG commands) which are routed to
the real user. Any other commands are ignored as there should be no need
for such aliasing.
The list of nicknames to reserve SIDs for is read from a space-separated
list in the reserved_sids parameter of the config file. The reserved
users must also be registered users (i.e., given a password) -- if they
are not, the alias is not set up for them.
Can send to either the currently selected user (the %[userSID] keyword
substitution) or a given SID. To make the latter useful (e.g, for
commands sent to a bot) support for static SIDs is needed.
The user command (UCMD) extension to the ADC protocol allows for sending
hub-specific commands to clients. These commands have a name (which
generally appears in a menu in the client) and a command string which
the client sends back to the hub when the command is selected. These
command strings can contain keyword substitutions for useful
information, such as the SID of another user that was selected in the
client.
This commit adds some support for sending user commands to the uhub
plugin API. It currently restricts the command string to containing main
chat messages (BMSG commands in ADC parlance).
A plugin_ucmd structure is added to store the details of a user command,
and four methods are added to the plugin_handle.hub structure:
* plugin->hub.ucmd_create(plugin, name, length) creates a new user
command.
* plugin->hub.ucmd_add_chat(plugin, ucmd, message, me) adds a main chat
message to the list of commands to be run when the user command is
selected. The me flag allows IRC /me style messages.
* plugin->hub.ucmd_send(plugin, user, ucmd) sends the command to a user.
* plugin->hub.ucmd_free(plugin, ucmd) frees the memory taken by a user
command.
The structure has a number of flags (categories, remove, separator,
constrained) which correspond to the flags in the UCMD specification.
The categories flag must be set prior to sending to one (or more, via
a logical OR) of the ucmd_category_* enumeration values defined in
plugin_api/types.h.
The PLUGIN_API_VERSION has been increased to 2 to mark the change.
uhub did not have this security bug since the hub did not advertise support for the
UCMD extension, but the message was still correctly relayed as specified in the
protocol specification.
However, this commit adds support for the UCMD extension, but only to the extent
that uhub will advertise it and uhub will also drop any such CMD message
generated by a client and will (currently) never issues a CMD message by itself.
GnuTLS sends a handshake with SSL 3.0 (0x0300) in the outer packet, but
mentions TLS 1.2 (0x0303) in the Client Hello. There's no real need for
uhub to validate these fields, as OpenSSL should do that itself already.
Just use the version mentioned in Client Hello for logging output.
It's not called anywhere yet.
Also reorder some typedefs, rename the ip check functions and add
struct {hub,plugin}_user parameter to on_check_ip_late(). Not sure where
to insert a call to that...
