After recent changes, '--foo bar' was working, but '--foo=bar' was not. The
test had a typo (?) (bar != baz) and because util.argparse is not strict by
default, the typo was not caught.
The typo caused the code to take a different path, and bypassed the buggy
handling of --foo=bar options.
I've preserved the existing test (typo and all!) because it's still an
interesting test, and ensures no unintended behaviour changes compared to the
old code.
However I've added a new variant of the test, with strict mode enabled and the
typo fixed. This test failed due to the bug, and this commit introduces a fix.
The :clean_clone() method is designed to provide a new cloned SASL handler,
to be used when starting a fresh SASL negotiation on an existing connection.
The userdata field is currently populated by mod_saslauth with the "read-only"
information that the channel binding methods need to do their stuff.
When :clean_clone() does not preserve this, it causes tracebacks in the cb
profile handlers due to the property being nil.
This does mean that SASL handlers should now not be reused (even when cloned)
across different connections, if they ever could.
Delays the string interpolation until the warning is logged, which may
slightly lower memory usage.
Allows retrieving the filename and line number easily.
A Credential in the global section would be stored at
delayed_warnings["*/secret"], but get("example.com","secret") would look
for delayed_warnings["example.com/secret"]
Storing the warnings in the config itself has the unfortunate
side-effect that the config now contains util.error objects, which may
be awkward if something bypasses get(). Should rawget() also do this
filtering? getconfig() too?
Currently this only affects prosodyctl, so maybe it won't be much of a
problem.
The WIP groups support is not complete yet, and won't work without extra
modules (which are not yet a part of Prosody). For now we hide --group support
unless mod_invites_groups (community module) is specified in modules_enabled.
This allow a shell-command to provide a 'flags' field, which will automatically
cause the parameters to be fed through argparse.
The rationale is to make it easier for more complex commands to be invoked
from the command line (`prosodyctl shell foo bar ...`). Until now they were
limited to accepting a list of strings, and any complex argument processing
was non-standard and awkward to implement.
Changes from community version:
- Add options to allow explicit control over whether BOSH/WS is advertised
- Always serve XML at /host-meta (no guessing based on Accept), least surprising
Inspired by mod_compliance_*, this command will help people (especially those
with older configs, upgrading from previous releases) learn what features
their Prosody configuration may be missing.
