There is a contradiction between Sopel's docs for the core.owner and core.admins settings, and how those values are actually used.
What's wrong?
According to the docs, under both "The [core] configuration section" and "Core Config Section" pages, examples show only nicknames under both of these settings. But internally, a Triggercan treat them as user@host regex patterns, too:
This ability doesn't appear anywhere in the documentation, perhaps because it breaks intended usage of the setting values in other places. core.owner, for example, is used in coretasks and third-party plugins as the target for important messages about the bot's configuration or errors. That value must be a nickname, not a user@host regex, for those uses to work.
How should we fix it?
We already have owner_account and admin_accounts, which are used if the server supports account-tag or otherwise attaches a services account name to messages in a way that Sopel can parse.
As a middle ground, there should exist owner_host and admin_hosts settings. The names are subject to revision, but their function is clear: Stricter controls on owner/admin identification beyond simple nickname matching, where account matching isn't available.
I propose a tiered enforcement system like this, described for owner but applied to both (just to save me some typing):
Only owner set: Match on nickname
Here is the reason for putting this in 8.1.0: We need to plan ahead, add the new settings, and raise deprecation warnings for detectable cases of behavior that will be removed in 9.0, meaning @ or other nick-invalid characters in one of the owner or admins values.
owner and owner_host set: Match on user@host
owner and owner_account set: Match on account name
owner, owner_host, and owner_account set: Match account name
In summary, if either host or account settings exist, nickname matching is ignored, period. The account always takes priority, same as it does now; if the IRCd has services accounts, we defer to its authorization mechanism(s).
But what about admins?
Yes, I said that the above would apply to admins, but there's another consideration: Sopel can have only one owner, but multiple admins. We might need to validate the configuration by comparing the length of admins and admin_accounts, though there are plenty of cases I could see where admin_accounts or admin_hosts would not be the same length as an admins list based on nicks only. (Grouped nicks and common host cloaks are just two of many possibilities.)
There is a contradiction between Sopel's docs for the
core.ownerandcore.adminssettings, and how those values are actually used.What's wrong?
According to the docs, under both "The [core] configuration section" and "Core Config Section" pages, examples show only nicknames under both of these settings. But internally, a
Triggercan treat them asuser@hostregex patterns, too:https://github.com/sopel-irc/sopel/blob/6fc9eee6585082f8794d91dabde2d8ffb1e1d447/sopel/trigger.py#L548-L563
This ability doesn't appear anywhere in the documentation, perhaps because it breaks intended usage of the setting values in other places.
core.owner, for example, is used incoretasksand third-party plugins as the target for important messages about the bot's configuration or errors. That value must be a nickname, not auser@hostregex, for those uses to work.How should we fix it?
We already have
owner_accountandadmin_accounts, which are used if the server supportsaccount-tagor otherwise attaches a services account name to messages in a way that Sopel can parse.As a middle ground, there should exist
owner_hostandadmin_hostssettings. The names are subject to revision, but their function is clear: Stricter controls on owner/admin identification beyond simple nickname matching, where account matching isn't available.I propose a tiered enforcement system like this, described for
ownerbut applied to both (just to save me some typing):ownerset: Match on nickname@or other nick-invalid characters in one of theowneroradminsvalues.ownerandowner_hostset: Match onuser@hostownerandowner_accountset: Match on account nameowner,owner_host, andowner_accountset: Match account nameIn summary, if either
hostoraccountsettings exist, nickname matching is ignored, period. Theaccountalways takes priority, same as it does now; if the IRCd has services accounts, we defer to its authorization mechanism(s).But what about admins?
Yes, I said that the above would apply to admins, but there's another consideration: Sopel can have only one owner, but multiple admins. We might need to validate the configuration by comparing the length of
adminsandadmin_accounts, though there are plenty of cases I could see whereadmin_accountsoradmin_hostswould not be the same length as anadminslist based on nicks only. (Grouped nicks and common host cloaks are just two of many possibilities.)