This is either caused by an earlier failure to bind http/s ports, in
which case that should be corrected, or explicitly disbling the http/s
ports, in which case ... why enable http modules?
Suggested by jonas’
When http_external_url is set then the portmanager usage only really
serves as a check of whether any http service is enabled at all.
Should allow generating an URL from prosodyctl when http_external_url is
set.
The roster version is stored in a pseudo-item which has the key `false`.
The if condition in the touched code attempts to guard against this, but
it does not take into account that the jid prepping returns nil instead
of false.
By moving the jid prepping into the if, we can check for the metadata
entry safely.
Since accessing this port directly over the wider Internet is unlikely
to intentional anymore. Most uses will likely be by reverse proxies, by
mistake or because of trouble configuring HTTPS.
Blocking mistaken uses is just a good thing, letting users send
potentially private things unencrypted tends to be Strongly Discouraged
these days.
Many reverse proxy setups operate over loopback, so listening there
instead of all interfaces is a net improvement.
Improved automatic certificate location and SNI support has mostly
eliminated the need for manual certificate configuration so HTTPS should
Just Work once certificates have been provided.
For local testing during development, connecting over loopback is likely
fine as well. When really needed, `http_interfaces` can still be set.
Suggested by Link Mauve
If the timer activates a bit early then a task might be just a few
seconds short of being allowed to run. This would run such a task rather
than wait another hour.
The value 0.5% chosen so that a weekly task does not run an entire hour
earlier than last time.
Metrics available or not depending on configuration is weird, even tho
it might be expensive to calculate and it's only really needed when
there is a global quota.
Default quota is set to infinity, which is essentially what it was.
Reports NaN if there is an error, which should count as over the
infinite default quota.
Found by accidentally publishing {urn:xmpp:bookmarks:0}conference
instead of :1 due to testing this earlier for the blocking.
By the principle of garbage in, garbage out, just generate a bookmark
from the item id / JID and carry on with a warning.
Having both the :0 and :1 nodes would be especially awkward, since there
is no upgrade path for this case. In theory, these should be rare since
no clients should have been doing XEP-0402 unless mod_bookmarks(2) was
enabled. This was guesstimated to be rare with most clients doing
XEP-0048 with Private XML.
Doing this when creating a whole new session seems reasonable because it
is already expensive and this is when it may be adding to the old
session store, while a successful resumption should be plus-minus zero.
More security for less pain than switching to SCRAM-SHA-256
The XEP will likely be change to reference the RFC that will probably
come from draft-ietf-kitten-password-storage once it is ready, and then
we should update to follow that.
Presence subscriptions are normally revoked on account deletion, which
informs the contact. Sometimes this notification gets lost e.g. due to
s2s problems. The accounts JID may also be present e.g. in MUC
affiliations, chat group member lists, pubsub subscriptions or other
systems. These may grant privileges which would fall to someone who
creates the same account again, which this module is meant to prevent.
UUID seems like insane overkill for something user-scoped and not
security-sensitive. All that is needed is to avoid conflicts among what
should be relatively long-lived sessions.
Matthew Wild