This information can now be retrieved on-demand using the debug:cert_index()
command, so we don't need to log it after every scan (it is rather verbose).
This was an unintentional regression, as per-host 'ssl' options became valid
in 0.12 when SNI support was added for direct TLS ports. While we encourage
most people to use the simpler automatic certificate selection (and it seems
most do, given the overlooking of this bug), there are likely always going to
be use cases for manually-configured certificates.
The issue was introduced in commit 7e9ebdc75ce4 which inadvertently removed
the per-host option checking for SNI.
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.
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
Too much noise to use Credential if you get a pile of warnings every
time you touch prosodyctl for anything. This way warnings should be
printed only if e.g used by prosodyctl check config or a module command.
Idea is to enable easily retrieving of secret values from files outside
of the config, e.g. via the method used by systemd credentials.
CREDENTIALS_DIRECTORY is expected to be set by the process manager
invoking Prosody, so being unset and unavailable from prosodyctl is
going to be normal and a warning is reported in that case. Care will
have to be taken to make it clear that prosodyctl check will not work
with such values. An error is thrown if the directory is unavailable
when running under Prosody.
Inspired by something MattJ said
Allows retrieving config values from files which are expected to be
relative to the config directory, extending on the ENV_ method of
retrieving config values from outside the config file.
- FileLine retrieves the first line, stripping any trailing newline
- FileContents reads the whole file
- FileLines reads lines into an array
This improves consistency. Previously the 'source' field was only
provided in the original event when an item was added. It is used to
report the name of the module providing the item in a few places.
Also considered adding a new API to modulemanager returning a mapping
of items per module and then using that here.
This removes one manual (yet undocumented) step that was supposed to be
done to get a complete 'intermediate' configuration.
This file can be found on the Internet by searching for "ffdhe2048" and
can be verified by comparing the hexadecimal representation of p from
the RFC with the output of `openssl asn1parse`.
Given the preference and prevalence of ECDHE, it seems likely that few
would have noticed this.
Could be used to implement custom connection methods (c.f. mod_onions)
without needing to duplicate the rest of route_to_new_session().
Adds a feature to enable detection since it can be difficult to detect
support for an event otherwise.
On regular disconnects, </stream> is sent, then
sessionmanager.destroy_session() is called, then
sessionmanager.destroy_session() is called again when the TCP connection
is closed, from ondisconnect in mod_c2s.
It is a bit annoying and doesn't really tell you much.
Normally with bidi, any outgoing connection should be the same as the
incoming, hence when closing a bidi connection it should be removed as a
route to the remote server. However it is not guaranteed, a remote bidi-capable server
might have decided to open a new connection for some reason. This can
lead to a situation where there are two bidi connections, and the s2sout
route is a locally initiated s2sout connection. In this case, such a
s2sout connection should be kept.
Noticed in a rare case where bidi has just been enabled on a running
server, and something establishes new connections immediately when a
connection is closed.
The 'global' property should reflect whether the module API instance
represents the global context or a VirtualHost or Component context.
However the module:context() method did not override this, leading the
property of the previous module shining trough, leading to bugs in code
relying on the 'global' property.
See also #1736
This flag is something of a shortcut for `module.host == "*"` and should
always be equal to that. Its absence on the proxy object made the
property of the global module instance visible, causing problems such as
with URL reporting in mod_http
Matthew Wild