| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This ensures that someone on your blocklist is unable to invite you to MUC
rooms.
|
| |
|
|
|
|
| |
Similar to 26c30844cac6
|
|
|
|
| |
`result[, err]`, not `ok, err|result`, must have confused it with pcall
|
|
|
|
|
| |
The unstable hash table order caused the tests to fail and I don't know
how to tell scansion to ignore the order.
|
|
|
|
|
| |
Discovered while experimenting with a stricter SystemCallFilter setting
See man:systemd.exec(5)
|
|
|
|
|
|
| |
This adds an output format option to show the time that the connection was created.
Ref #1852
|
|\ |
|
| | |
|
| |
| |
| |
| | |
Why do we not have tests for this?
|
| |
| |
| |
| | |
(thanks nicoco)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
This fixes a traceback with mod_saslauth. Ideally we move this to util.session
at some point, though.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
conn:ssl_peerverification() can now return a single error in case the
connection has been closed for whatever reason
|
| |
| |
| |
| |
| | |
Notably, it is now possible to add a randomized spread factor to the check
interval.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
Fixes a test case provided by MattJ where the very first item matched by
a 'start' timestamp was not returned.
|
| |
| |
| |
| | |
Moves some complexity from the implementation into DNS operations.
|
| |
| |
| |
| | |
Fewer loops
|
| | |
|
| |
| |
| |
| |
| | |
Not sure what the next() was supposed to do. Reject unknown --options
perhaps?
|
| | |
|
| |
| |
| |
| |
| | |
Because I couldn't guess the right way to get the help message without
reading the source twice.
|
| |
| |
| |
| | |
Was missing a way to pass TTL via command or shell.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This matches the behaviour of the newer mod_sasl2 implementation. It allows
plugins to observe (and potentially, with caution, modify) the SASL exchange.
|
| |
| |
| |
| | |
E.g. the timeout could be extended under certain conditions.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This merges the mod_s2s_smacks_timeout behavior from prosody-modules
This event is fired by mod_smacks when the connection has not responded
to an ack-request for a period of time defaulting to 30 seconds,
indicating that the connection has become stuck or non-responsive.
Closing it prevents routing further messages via this connection and
frees resources. A stuck connection may otherwise remain until for a
time determined by the OS TCP subsystem, which can be quite long.
|
| |
| |
| |
| |
| |
| | |
As extension point for rate limiting and similar checks, so they can
hook a single event instead of <{sasl1}auth> or stream features, which
might not be fired in case of SASL2 or e.g. HTTP based login.
|
| |
| |
| |
| |
| |
| |
| | |
Previously these events fired after the session had been destroyed, which
removes many of the useful properties. The ones I chose to preserve here are
the ones used by the community module mod_audit, which seems like a good
baseline.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When registration_delete_grace_period is set, accounts will be disabled for
the specified grace period before they are fully deleted.
During the grace period, accounts can be restored with the user:restore()
shell command.
The primary purpose is to prevent accidental or malicious deletion of a user's
account, which is traditionally very easy for any XMPP client to do with a
single stanza.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This allows us to store a time, actor, comment and/or reason why an account
was disabled, which seems a generally useful thing to support.
|