|
9 months ago | |
---|---|---|
a2 | 3 years ago | |
.editorconfig | 9 months ago | |
LICENSE | 6 years ago | |
README.md | 3 years ago |
So besides writing UnrealIRCd and ZNC modules, I now also do Anope shit. =]
The shown config block snippets are mostly just examples, it's up to you to integrate it properly with your existing config
Since it may be a little hard to find, here's a wiki page that describes how to compile third-party mods.
There may be some compiler warnings from third-party modules, but they are generally safe to ignore. =]
As is common with Anope mods, every module's filename is prefixed with the abbreviation of the service it applies to (e.g. ns_
means NickServ
).
This README contains all modules and their descriptions/usage info (ordered from new to old). Modules that have PORTED
behind their name tell you that I've ported them. If it says UNC
(uncommon) or has no tag at all, that means I wrote it from scratch fam. There will be others but they should be self-explanatory. =]
Module | Description |
---|---|
ns_sagroup | Allows services operators/admins to group/ungroup other people's nicknames |
ns_saregister (PORTED) | Allows services operators/admin to manually register new nicknames (without verification) |
ns_regcode (PORTED) | Instead of verifying nick registrations by email, use a "registration code" |
Requested by Mi_92
, this module allows services operators/admins to group/ungroup nicknames on behalf of others. You cannot use this to change groups related to operators/admins, they have to use regular /ns GROUP
commands themselves. It abides by the same rules as REGISTER
for nicknames and shit. ;]
Updated shit:
/ns group
command, we now also allow them to modify only their own groupsUsage:
Edit your nickserv.conf
so it contains the following:
module {
name = "ns_sagroup"
}
command { service = "NickServ"; name = "SAGROUP"; command = "nickserv/sagroup"; permission = "nickserv/sagroup"; }
command { service = "NickServ"; name = "SAUNGROUP"; command = "nickserv/saungroup"; permission = "nickserv/saungroup"; }
The permission
bit is essential, otherwise everyone who's identified could use it. By default only opers with opertype Services Root
will be able to use em. If you want to allow other opertypes, make sure it's in their respective commands
directive in services.conf
:
opertype {
name = "Services Op - sagroup"
inherits = "Services Operator"
commands = "nickserv/sagroup nickserv/saungroup"
}
Keep in mind that if you UNGROUP
someone and a channel's SECUREOPS
setting is disabled, they'll retain their old group's channel operator modes until they /cycle
. On the other hand, simply GROUP
ing a user results in them getting all the modes the target nick is supposed to have.
Originally written by Adam
, this allows services admins to manually register a nick for someone (without having to confirm shit, which may be the case for other variants), like if you have email confirmation enabled but their provider is being gay. It abides by the same rules as REGISTER
for nicknames and shit. ;]
Usage:
Firstly, fire up een edit0r and edit your nickserv.conf
. Put this in thur:
module {
name = "ns_saregister"
}
command { service = "NickServ"; name = "SAREGISTER"; command = "nickserv/saregister"; permission = "nickserv/saregister"; }
The permission
bit is essential, otherwise everyone who's identified could use it. By default only opers with opertype Services Root
will be able to use em. If you want to allow other opertypes, make sure it's in their respective commands
directive in services.conf
:
opertype {
name = "Services Op - saregister"
inherits = "Services Operator"
commands = "nickserv/saregister"
}
The original idea was conceived by n00bie
. Basically instead of emailing a passcode NickServ
simply says Confirm your nick registration using PROCEED <regcode>
.
I'm not really familiar with Anope modules and there's no documentation on how to (properly) write a module for it. So, I just cooked something up based on the logic of the code of the core/built-in mods. =] I basically copied ns_register
and added a command PROCEED
, more on that below. Other than that, the CONFIRM
command is effectively disabled if you use this new auth method. The main reason is because CONFIRM
is tailored to confirmation emails and I didn't want to change too much of the current functionality. ;]
Usage:
You have to load the module in place of ns_register
because otherwise (judging by the code), you'd get multiple notifications (one from ns_register
and another from ns_regcode
).
In nickserv.conf
, you'll most likely have a module { }
block with a directive name = "ns_register"
in it. Change that to name = "ns_regcode"
, then adjust the registration method to regcode
. Finally add a command { }
block. Check below for a full example.
module {
name = "ns_regcode" // Drop-in replacement
registration = "regcode" // Use regcode instead of mail, none or admin
nickregdelay = 30s // Optional but included for completeness
unconfirmedexpire = 1d // Ditto
}
command { service = "NickServ"; name = "CONFIRM"; command = "nickserv/confirm"; } // Was already there, just leave it ;]
command { service = "NickServ"; name = "REGISTER"; command = "nickserv/register"; } // Register might be useful, dontcha tink?
command { service = "NickServ"; name = "RESEND"; command = "nickserv/resend"; } // Was already there, just leave it ;]
command { service = "NickServ"; name = "PROCEED"; command = "nickserv/proceed"; } // New one for regcodes
After these changes you'll most likely have to restart Anope lel.