Add human-readable description parameters to multiline fail messages,
since they are technically required by the standard-replies spec
(although the utility of showing them to users is dubious)
We were checking the login throttle at the beginning of every SASL
conversation. This had several problems:
1. Pidgin (on Windows?) tries every mechanism in order, regardless of
the CAP advertisement. It would use up the default throttle allowance
trying unsupported mechanisms like CRAM-MD5.
2. The throttle was actually checked twice for AUTHENTICATE PLAIN
(once at the start of the conversation and once in AuthenticateByPassphrase).
The general pattern here is that we should check the throttle every time we
do something "expensive" (bcrypt verification, send a reset email) or
"dangerous" (anything that could lead to a bruteforce attack on passwords).
Therefore, delete the check from the AUTHENTICATE handler, and add one at
the beginning of the SCRAM conversation to replace it.
Handling of reserved nicknames is special-cased due to #1594, but we want to send
ERR_NICKNAMEINUSE if the nickname is actually in use, since that doesn't pose any
client compatibility problems.
We load registered channels unconditionally; reloading them again on rehash
is incorrect. This caused buggy behavior when channel registration was
disabled in the config, but some registered channels were already loaded.
* Gracefully handle NS cert add myself <fp>
A non-operator with the nick "mynick" attempts to register
a fingerprint to their authenticated account.
They /msg NickServ cert add mynick <fingerprint>
NickServ responds with "Insufficient privileges" because
they've accidentally invoked the operator syntax (to action
other accounts).
This patch allows the user to add the fingerprint if the client's
account is identical to the target account.
Signed-off-by: Matt Hamilton <m@tthamilton.com>
* Update nickserv.go
Compare the case-normalized target to Account()
---------
Signed-off-by: Matt Hamilton <m@tthamilton.com>
Co-authored-by: Shivaram Lingamneni <slingamn@cs.stanford.edu>
* Explain reverse proxy setup for websockets
* Update MANUAL.md
Clarify that we only support `X-Forwarded-For`
---------
Co-authored-by: Shivaram Lingamneni <slingamn@cs.stanford.edu>
