This allows greater control over the order of events.
Notably, the internal ordering between daemonization, initialization of
libunbound and setup of signal handling is sensitive.
libunbound starts a separate thread for processing DNS requests.
If this thread is started before signal handling has been set up, it
will not inherit the signal handlers and instead behave as it would have
before signal handlers were set up, i.e. cause the whole process to
immediately exit.
libunbound is usually initialized on the first DNS request, usually
triggered by an outgoing s2s connection attempt.
If daemonization happens before signals have been set up, signals may
not be processed at all.
When libunbound is initialized, it spawns a thread to work in.
In case a module initializes libunbound, e.g. by triggering a s2s
connection, Prosody would not handle signals, instead immediately quit
on e.g. the reload (SIGHUP) signal. Likely because the libunbound thread
would not have inherited the signal mask from the main Prosody thread.
Thanks Menel, riau and franck-x for reporting and help narrowing down
This allows multiple modules to populate the form dynamically. Currently the
form is "owned" by mod_server_contact_info, which prevents other modules from
contributing to it.
A further commit will port mod_server_contact_info to use this module.
Given that there are recommendations floating around recommending 24
hours session lifetime, having buckets up to 10 minutes wouldn't be
useful in that case.
Would be nice if we had some way to automatically assign suitable number
series for buckets, scaled to what the configuration might be.
Having to add these in *there* places seems less than ideal.
I would also think that advertising disco#info is a bit redundant, since
it is a requirement for everything in XMPP and if it was missing you
would get an error back.
Suggested by jstein in the chat
This option label is used by XMPP clients to explain what the option does.
a) The user should know where the data is archived.
b) The user needs a statement that can be enabled/disabled by the variable. A question would have the wrong logic here.
Because it changes the type of the 'opt_origins' variable from util.set
to the internal _items table so next time an http app is added an error
"attempt to call a nil value (method 'empty')" is triggered. The value
is not used anywhere else.
Noticed when reviewing uses of the '_items' set property.
Not reported by any users, implying this setting is rarely used.
From XEP-0191:
> For message stanzas, the server SHOULD return an error, which SHOULD
> be <service-unavailable/>.
Following this may leak to a blocked JID that they have been blocked,
which seems contrary to the goal of pretending to be perpetually
offline.
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.
It should not be there afterwards. Noticed that it seems to fire some
time after resumption claiming that the queue size is nil, implying
that it may hold a reference to an expired session somehow.
There shouldn't be one here but if there is, for some reason, it's
better to close it than have it around to wake up and possibly try to
destroy the session.
This event was added in a7c183bb4e64 and is required to make mod_smacks know
that a session was intentionally closed and shouldn't be hibernated (see
fcea4d9e7502).
Because this was missing from mod_websocket's session.close(), mod_smacks
would always attempt to hibernate websocket sessions even if they closed
cleanly.
That mod_websocket has its own copy of session.close() is something to fix
another day (probably not in the stable branch). So for now this commit makes
the minimal change to get things working again.
Thanks to Damian and the Jitsi team for reporting.
When mod_admin_socket is loaded without mod_admin_shell, attempt to use
`prosodyctl shell` will appear to freeze after any input, since no
response is returned.
Fixes `prosodyctl adduser` etc.
Prior to d580e6a57cbb the line did nothing.
Sometimes storage in the prosodyctl context does cause weirdness, as it
is not in a host context, but rather a variant of global.
Since resumption is not supported on s2s currently, there is no point in
allocating resumption tokens. The code that removes entries from
session_registry is only invoked for c2s sessions, thus enabling
resumable smacks on s2s adds an entry that never goes away.
Fixes#1779.
Due to an oversight in the logic, if the user set 'enabled' to false in an
override, it would disable the item's requested CORS settings, but still apply
Prosody's default CORS policy.
This change ensures that 'enabled = false' will now disable CORS entirely for
the requested item.
Due to the new structure of the code, it was necessary to have a flag to say
whether CORS is to be applied at all. Rather than hard-coding 'true' here, I
chose to add a new option: 'http_default_cors_enabled'. This is a boolean that
allows the operator to disable Prosody's default CORS policy entirely (the one
that is used when a module or config does not override it). This makes it
easier to disable CORS and then selectively enable it only on services you
want it on.
user:roles() does not convey that this is the mutating command, it
should have been called setroles from the start but wasn't due to lack
of foresight. This has to accidentally removing roles when wanting to
show them.
The ORDER BY and LIMIT clauses are not needed and don't even make much
sense. This part was most likely a leftover from the :find method.
Tested with sqlite and postgres 14
