| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
To match the variable name and what systemd calls them.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
If this module is require'd from a plugin on a Lua version without the
global bit32 library, it may trip a warning about accessing globals.
|
|
|
|
| |
Removed the one without error handling.
|
|
|
|
| |
Was supposed to be part of commit 2f38f3275a74.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bestows the role specified by the 'host_user_role' setting onto
users of that host. For simplicity, only a single host can be specified.
Making it configurable allows for setups where VirtualHost and related
Components may be siblings instead of having a subdomain relationship.
For setups with many VirtualHosts sharing a single Component, the
'server_user_role' setting is more appropriate. Even more complicated
setups would have to resort to mod_firewall or similar.
|
| |
|
|
|
|
| |
Makes it easier to keep them in sync when the diff is smaller
|
|
|
|
| |
Makes it easier to test by disabling this #define
|
|
|
|
|
|
| |
The Lua hook based signal handling does not work correctly if signal
handling is setup in a coroutine. signalfd solves that in a nice way,
but is Linux-only.
|
|
|
|
|
|
| |
Many thanks to Thilo Molitor and Kim Alvefur for their work on this module
while it was in the community repository. It has been stable for some time, is
widely used, and provides a feature that is important to most deployments.
|
| |
|
|
|
|
|
| |
Lua has a slow release cycle, but it would be nice if Prosody doesn't break
unnecessarily with 5.10 :)
|
|
|
|
|
|
|
|
|
|
|
| |
This allows Prosody to easily provide friendly invitation links, even without
setting up mod_invites_page (which is a community module). Admins can
configure it to use a third-party deployment such as https://xmpp.link or they
can deploy their own based on
https://github.com/modernxmpp/easy-xmpp-invitation
Alternatively they can just install mod_invites_page and this will all be
handled automatically by that.
|
|
|
|
|
|
| |
All commands are called with a '-h' argument, but this one doesn't have
that. Since it's meant to be machine readable, hiding it seems
marginally more sensible than implementing '-h'.
|
|
|
|
|
|
| |
The word 'error' anywhere, especially in harmless debug messages, are
too often interpreted as fatal errors my some users, so best avoid that
word. These look too scary as it is, being tracebacks.
|
|
|
|
|
| |
This can be useful to run scripts and stuff with access to the same Lua paths
as Prosody uses.
|
|
|
|
| |
The 'about' command remains for backwards compatibility, but hidden.
|
| |
|
| |
|
|
|
|
| |
Leftover after 854df134274f
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
The field `_provided_by` comes from module:provides(), but these items
comes from moduel:add_item(), which include the originating module as a
'source' field of the event. However, this is absent when items are
retrieved at a later time than the initial event.
|
|
|
|
| |
This produced a *lot* of noise, especially listing items.
|
|
|
|
|
|
|
| |
Ensures that nodes that one does not have metadata access to are hidden
from view.
This follows from the new ACL-aware method added in 3b357ab6b6eb.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This allows user creation to happen inside the running Prosody process, which
improves a number of things - such as executing event handlers for user
creation, fixing issues and race conditions with some storage drivers, etc.
The intent is to do the same for the other prosodyctl commands, but this is
the first proof of concept for the approach.
|
| |
|
|
|
|
| |
client
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to continue sending/receiving on the session, for example if
the promise will be resolved by other data that the client is going to send.
Specifically, this allows the repl-request-input to work without a deadlock.
It does open the door to interleaved commands/results, which may not be a good
thing overall, but can be restricted separately if necessary (e.g. a flag on
the session).
|
|
|
|
|
| |
This lets the server signal to the client that a special input is requested.
Currently we support the "password" type only.
|
|
|
|
| |
Currently there is no way to get this info and perform cleanup tasks.
|
|
|
|
|
| |
It's common for modules to depend on mod_cron, and this can lead to it loading
inside prosodyctl, where we don't really want to run any cron tasks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes an issue where e.g. remote users or even other users on the server
were unable to list MUC rooms.
We want to define a permission to list MUC rooms, but we want it to be
available to everyone by default (the traditional behaviour).
prosody:guest is the lowest role we have. I ran a quick check and it isn't
really used for anything right now that would be concerning.
It was originally designed for anonymous logins. I think it's safe to treat
remote JIDs as equivalent, since we have no trust relationship with anonymous
users either.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This will be useful for server operators to easily identify flagged accounts,
etc.
|
| |
|
|\ |
|
| |
| |
| |
| | |
Not necessarily a fix, but may give us more information about failure cases.
|