| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
These two settings are only really needed for XMPP server-to-server
connections.
|
| |
|
|
|
|
| |
Revert with muc_hats_compat = true in the config if necessary.
|
| |
|
|
|
|
|
| |
This is more readable and accessible, and it will only be harder to change
after release.
|
|
|
|
|
|
|
|
|
| |
Secondary roles are an advanced feature without any strong use cases
currently. Having multiple ways to manage roles is confusing.
Now the 'user:role' command will just show the primary role if that is all
there is, but will list secondary roles too if there are any (which in 99.9%
of cases there won't be).
|
|
|
|
| |
Useful for e.g. deprecated commands.
|
| |
|
| |
|
| |
|
|
|
|
| |
usermanager expects (role, err) and (ok, err)
|
|
|
|
| |
Fixes #1887
|
| |
|
| |
|
|
|
|
| |
Including accounts which may never have logged in.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is similar to mod_lastlog/mod_lastlog2.
Some functionality was dropped, compared to mod_lastlog2. These features
(recording the IP address, or tracking the timestamp of multiple events) are
handled better by the mod_audit family of modules. For example, those
correctly handle multiple logins, IP address truncation, and data retention
policies.
The "registered" timestamp from mod_lastlog2 was also dropped, as this has
been stored in account_details by Prosody itself since at least 0.12 already.
|
|
|
|
| |
Tests does not run the code that initializes `sqlite_version`
|
| |
|
| |
|
|
|
|
|
|
| |
This was previously served by a community module (mod_vcard_muc).
It can be disabled by setting `vcard_muc = false` in the config.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
The array:pluck() method mutates the args, replacing the table items
with the resulting strings. On later runs I assume it tries to index the
string, which returns nil, emptying the array.
|
|
|
|
|
|
|
|
|
| |
Because the code was using `< now` in a lot of places, things expiring at the current second
wouldn't be marked as expired. It isn't noticeable in real-world scenarios but I wanted to
create OAuth 2.0 tokens valid for 0 second in integration tests and it wasn't possible.
By using `<=` instead of `<`, we make sure tokens don't live a single millisecond more than
what they are supposed to.
|
|
|
|
|
| |
It seems to imply that No is the default, so it shouldn't continue doing
the Yes action unless you actually press Y
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SQLCipher v3.4.1 (the version in Debian 12) is based on SQLite3 v3.15.2,
while UPSERT support was introduced in SQLite3 v3.24.0
This check was not needed before because we v3.24.0 has not been in a
version of Debian we support for a long, long time.
Note however that SQLCipher databases are not compatible across major
versions, upgrading from v3.x to v4.x requires executing a migration.
Attempts at making `prosodyctl mod_storage_sql upgrade` perform such a
migration has not been successful.
Executing the following in the `sqlcipher` tool should do the migration:
PRAGMA key = '<key material>';
PRAGMA cipher_migrate;
|
| |
|
|
|
|
| |
Removed the one without error handling.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
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).
|
|
|
|
|
| |
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.
|