- Only rewrite cloak => cloaking if the cloak_md5 module is also
loaded.
- Include the cloak method in the link data.
- If 1206 servers are using different cloak methods then ignore
the other data when telling operators about the link failure.
- Clean up the code in a few places.
Closes#1107.
The core of the cloaking algorithm this uses is heavily inspired
by the Plexus4 cloak_hmac_sha256 module written by Adam. I've made
a few changes to the rest of it to work more like the old InspIRCd
cloaking system as well as adding the option for configuring the
case of the character table used for cloaking.
Co-authored-by: Adam <Adam@anope.org>
Co-authored-year: 2017
- Move core connect class checks and <performance:clonesonconnect>
to the core_user module.
- Add pre-change and post-change events for when a connect class
changes.
- Split explicit class changing out into its own method.
- Remove the need to almost always call CheckClass after SetClass.
- Add use counting to the connect class instead of relying on the
shared_ptr use count.
- Fix adding -Wshadow in the compiler flags twice.
- Detect the new Clang-based Intel compiler as well as the old one.
- Silence some deprecation warnings using Intel syntax.
Stats responses are incredibly non-standard and no clients render
them correctly. This makes using /STATS a massive pain in the ass
for users.
However, now we have message tags we have a way to fix this. We can
send a <trailing> with the message details and for clients (probably
bots) that need to parse the response we can include the specific
details in message tags enabled by the new inspircd.org/stats-tags
capability.
The average user will get this:
:<server> 210 <nick> <stats-char> :<stats-message>
If however they enable the newcapability they will get this instead:
@inspircd.org/stats-foo=bar;inspircd.org/stats-baz=bax :<server> 210 <nick> <stats-char> :<stats-message>
A Cap::Reference can not be cast to a Cap::Capability& because it may
not be available and that would create a null reference. In v4 we can
change the API to take a Cap::Capability* but for now this is the best
we can do.
We previously referred to both session registration and user registration
as "registration" which is confusing for users who aren't familiar with
how IRC works.
This isn't used much currently but in the future will allow doing
a lot of behaviour which is currently implemented in services in
the IRCd instead e.g. killing ghost clients, nickname enforcement.
