| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
This change has various technical and social benefits. If ownership of a MUC
is really needed, it can be gained using the 'Set affiliation' ad-hoc command
or prosodyctl shell.
Example client incompatibility with the old behaviour:
- https://github.com/monal-im/Monal/issues/1085
|
|
|
|
| |
Based on mod_muc_restrict_pm in prosody-modules d82c0383106a
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Only supporting exact match on full JID isn't helpful if you want to
list sessions per host or user.
Backport of 430333198e4c
Fixes #1857
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
compliant behavior
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.
|
| |
| |
| |
| |
| |
| |
| | |
Allows e.g. restricting your vcard4 to only family or similar.
Notes: This does not include roster groups in the configuration form,
so the client will have to get them from the actual roster.
|
| | |
|
| | |
|
| |
| |
| |
| | |
Returning nothing/nil lets stanzas pass, returning anything else blocks
|
| |
| |
| |
| |
| | |
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.
|