aboutsummaryrefslogtreecommitdiffstats
path: root/plugins/muc
Commit message (Collapse)AuthorAgeFilesLines
* MUC: Fix legacy hats (thanks nicoco)Kim Alvefur2024-03-281-2/+8
| | | | Why do we not have tests for this?
* MUC: Switch to official XEP-0317 namespace for Hats (including compat) ↵Kim Alvefur2024-03-281-1/+10
| | | | (thanks nicoco)
* MUC: Record reason for affiliation changes and return in list (fixes #1227)Kim Alvefur2021-08-081-4/+11
|
* mod_muc: Switch to module:could() for some implicit access control checksMatthew Wild2023-11-071-2/+2
|
* mod_muc: Allow guest users to list rooms by defaultMatthew Wild2023-11-071-0/+3
|
* mod_muc: Add :list-rooms permissionMatthew Wild2023-11-071-1/+5
|
* muc.register: Clarify what's going on when enforcing nicknamesKim Alvefur2023-11-031-0/+2
| | | | Does this make it clearer what is going on?
* mod_muc: Use enum config API for 'restrict_room_creation'Kim Alvefur2023-07-211-1/+1
| | | | | | This communicates the accepted values in case the config diverges from them. Note that older documentation used an "admin" value behaving like an alias to true, but this is no longer handled. Should it?
* plugins: Use boolean config method in some placesKim Alvefur2023-07-181-4/+2
| | | | Because it makes sense and improves feedback via logging
* mod_muc: Use enum option method for 'muc_room_default_presence_broadcast'Kim Alvefur2023-07-181-1/+2
|
* plugins: Use integer config API with interval specification where sensibleKim Alvefur2023-07-172-4/+4
| | | | | | | Many of these fall into a few categories: - util.cache size, must be >= 1 - byte or item counts that logically can't be negative - port numbers that should be in 1..0xffff
* plugins: Switch to :get_option_period() for time range optionsKim Alvefur2023-07-162-2/+2
| | | | Improves readability ("1 day" vs 86400) and centralizes validation.
* core, plugins: Split prosody:user role into prosody:{guest,registered,member}Matthew Wild2023-06-293-3/+3
| | | | | | | This gives us more granular control over different types of user account. Accounts registered by IBR get assigned prosody:registered by default, while accounts provisioned by an admin (e.g. via prosodyctl shell) will receive prosody:member by default.
* plugins: Prefix module imports with prosody namespaceKim Alvefur2023-03-2413-42/+42
|
* MUC: Add note about non-existant room methodKim Alvefur2023-01-201-1/+1
|
* Backed out changeset 73a45ba6e3f1 in favour of 427dd01f0864Matthew Wild2022-09-291-3/+6
| | | | | | | | | | | | | New behaviour (muc_room_allow_persistent = true, the default): - Parent host users are not restricted by default (prosody:user) - Users without roles (by default that is non-admins, non-parent-host users, and users on other servers) can no longer configure persistence by default. muc_room_allow_persistent = false will restrict persistence to prosody:admin. Parent-host users should not be restricted by default, and this can be configured via the new roles/permissions options.
* mod_muc: Better map restrict_room_creation to role permissions (behaviour ↵Matthew Wild2022-09-291-21/+8
| | | | | | | | | | | | | | | | | | change) With this change and 427dd01f0864, room creation is now effectively restricted to parent-host users by default. This is a better default than previous Prosody versions (where room creation was not restricted). The "local" option for restrict_room_creation is no longer used (any value other than true/false won't change the default behaviour). restrict_room_creation = true will grant prosody:admin the ability to create rooms. restrict_room_creation = false disables all permission checks. Anything between these two can be achieved using custom roles and permissions.
* muc: Re-allow non-admins to configure persistence (thanks Meaz)Matthew Wild2022-09-281-6/+3
| | | | | | | | | | Non-admins don't have a role on MUC services by default. Not even prosody:user. This meant they had no :create-persistent-room permission, even if muc_room_allow_persistent was true (the default). Now we only check the role permissions if persistent room creation is restricted, otherwise we skip any permission checks, just like previous versions.
* Switch to a new role-based authorization framework, removing is_admin()Matthew Wild2022-06-153-16/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We began moving away from simple "is this user an admin?" permission checks before 0.12, with the introduction of mod_authz_internal and the ability to dynamically change the roles of individual users. The approach in 0.12 still had various limitations however, and apart from the introduction of roles other than "admin" and the ability to pull that info from storage, not much actually changed. This new framework shakes things up a lot, though aims to maintain the same functionality and behaviour on the surface for a default Prosody configuration. That is, if you don't take advantage of any of the new features, you shouldn't notice any change. The biggest change visible to developers is that usermanager.is_admin() (and the auth provider is_admin() method) have been removed. Gone. Completely. Permission checks should now be performed using a new module API method: module:may(action_name, context) This method accepts an action name, followed by either a JID (string) or (preferably) a table containing 'origin'/'session' and 'stanza' fields (e.g. the standard object passed to most events). It will return true if the action should be permitted, or false/nil otherwise. Modules should no longer perform permission checks based on the role name. E.g. a lot of code previously checked if the user's role was prosody:admin before permitting some action. Since many roles might now exist with similar permissions, and the permissions of prosody:admin may be redefined dynamically, it is no longer suitable to use this method for permission checks. Use module:may(). If you start an action name with ':' (recommended) then the current module's name will automatically be used as a prefix. To define a new permission, use the new module API: module:default_permission(role_name, action_name) module:default_permissions(role_name, { action_name[, action_name...] }) This grants the specified role permission to execute the named action(s) by default. This may be overridden via other mechanisms external to your module. The built-in roles that developers should use are: - prosody:user (normal user) - prosody:admin (host admin) - prosody:operator (global admin) The new prosody:operator role is intended for server-wide actions (such as shutting down Prosody). Finally, all usage of is_admin() in modules has been fixed by this commit. Some of these changes were trickier than others, but no change is expected to break existing deployments. EXCEPT: mod_auth_ldap no longer supports the ldap_admin_filter option. It's very possible nobody is using this, but if someone is then we can later update it to pull roles from LDAP somehow.
* MUC: Allow kicking users with the same affiliation as the kicker (fixes #1724)Matthew Wild2022-03-231-4/+5
| | | | | | | | | | This is allowed by XEP-0045, which states: "A moderator SHOULD NOT be allowed to revoke moderation privileges from someone with a higher affiliation than themselves (i.e., an unaffiliated moderator SHOULD NOT be allowed to revoke moderation privileges from an admin or an owner, and an admin SHOULD NOT be allowed to revoke moderation privileges from an owner)."
* MUC: Switch ID algorithm for IQ relay (fixes #1266, #1435)Kim Alvefur2021-10-051-3/+5
|
* MUC: Add method for getting the occupant id salt to allow reuseKim Alvefur2021-10-052-5/+12
|
* MUC: Remove <{muc}x> tags in some errorsKim Alvefur2021-12-084-6/+6
| | | | | Including the payload of the stanza that caused the error is optional and we're generally not doing it anywhere else.
* MUC: Fix error origin JID in wrong argument positionKim Alvefur2021-12-081-1/+1
| | | | | Mistake introduced in cbe524ed1a6a. Removing because this is a query to the bare JID where the error origin matches the resulting stanza 'from'.
* MUC: Remove remaining deprecated numeric error codesKim Alvefur2021-12-083-4/+0
| | | | | | The numeric error codes seems to have been removed from the examples in XEP-0045 version 1.24, and were deprecated even by RFC 3920 in 2004, only allowed for backwards compatibility.
* MUC: Return a friendly textual error when trying to speak without voiceKim Alvefur2021-12-081-1/+2
| | | | | | I spend several minutes confused over where the bug was until I remembered I had set myself as visitor in the previous debug session. This would have helped.
* MUC: Allow modules a chance to act prior to room destructionKim Alvefur2021-12-052-7/+19
|
* MUC: Actually set the new affiliation data if it was previously emptyMatthew Wild2021-11-161-0/+1
|
* MUC: Include old affiliation data in affiliation change eventMatthew Wild2021-11-161-0/+1
|
* MUC: Add room:set_affiliation_data()Matthew Wild2021-11-161-0/+22
|
* MUC: Set .previous_affiliation = "none" if nil, for consistency with ↵Matthew Wild2021-11-161-1/+1
| | | | | | .affiliation It appears nothing currently uses this field in prosody or prosody-modules
* MUC: Fix incorrect variable name (thanks luacheck)Matthew Wild2021-11-161-1/+1
|
* MUC: Switch to event.allowed signaling to block event, matching muc-pre-set-roleMatthew Wild2021-11-161-1/+3
| | | | ...and fixing the logic bug that broke everything in the previous commit.
* MUC: Add 'muc-pre-set-affiliation' event, allowing to block change or modify ↵Matthew Wild2021-11-161-10/+20
| | | | data
* MUC: Add option to include form in registration queryMatthew Wild2021-11-151-3/+11
| | | | | | | | | | | | | | | | | | | This was originally not done based on my interpretation of XEP-0045. Today's reading, however, revealed that it actually says the result > SHOULD contain **at least** a <username/> element (emphasis mine) I take this to mean that including a form **is** allowed (and I think this is sensible). Tigase already includes the form I believe. I've gated the new behaviour behind a (default off) option, because it hasn't been tested for compatibility with clients. My primary desire for it is in Snikket, where the clients will be tested to ensure compatibility with this. I don't anticipate that (m)any clients would break, so maybe after 0.12 we can experiment with enabling it by default and eventually remove the option.
* MUC: Reject full JID in affiliation queriesKim Alvefur2021-09-171-0/+3
| | | | | | | | | | XEP-0045 states: > Affiliations are granted, revoked, and maintained based on the user's > bare JID, not the nick as with roles. Therefore inclusion of a full JID in affiliation queries is invalid. Thanks to Ge0rG and Poezio for discovering this issue.
* Merge 0.11->trunkKim Alvefur2021-07-231-1/+1
|\
| * MUC: Fix logic for access to affiliation lists0.11.10Kim Alvefur2021-07-221-1/+1
| | | | | | | | | | | | Fixes https://prosody.im/security/advisory_20210722/ Backs out 4d7b925652d9
* | MUC: Skip adding to history when it's set to zeroKim Alvefur2021-07-191-0/+4
| | | | | | | | | | Optimizes away all the processing on every message in case the end-result is zero history.
* | Merge 0.11->trunkMatthew Wild2021-05-131-2/+10
|\|
| * MUC: Add support for advertising muc#roomconfig_allowinvites in room disco#infoMatthew Wild2021-05-101-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | The de-facto interpretation of this (undocumented) option is to indicate to the client whether it is allowed to invite other users to the MUC. This is differs from the existing option in our config form, which only controls the behaviour of sending of invites in a members-only MUC (we always allow invites in open rooms). Conversations is one client known to use this disco#info item to determine whether it may send invites.
* | MUC: Allow overriding occupant object from groupchat message eventKim Alvefur2021-03-251-4/+9
| | | | | | | | | | | | | | Use case: Enable module that provides a virtual occupant object for bots Before, if there is no occupant then either some other part of MUC would reject the message or `occupant.nick` would have caused an error.
* | MUC: Report number of live rooms to statsmanagerKim Alvefur2021-03-281-0/+5
| | | | | | | | Should help inform on whether the cache size should be increased.
* | MUC: Allow modules to add to the room registration form, and handle the resultMatthew Wild2021-01-151-0/+23
| |
* | MUC: Reject probes from non-occupantsJC Brand2020-10-021-12/+21
| | | | | | | | Also test for self-probes
* | MUC: Add support for presence probes (fixes #1535)JC Brand2020-04-192-24/+87
| | | | | | | | | | | | | | | | | | | | | | The following patch allows Prosody to respond to `probe` presences and send out the probed occupant's current presence. This is based on line 17.3 in XEP-0045: A MUC service MAY handle presence probes sent to the room JID <room@service> or an occupant JID <room@service/nick> (e.g, these might be sent by an occupant's home server to determine if the room is still online or to synchronize presence information if the user or the user's server has gone offline temporarily or has started sharing presence again, as for instance when Stanza Interception and Filtering Technology (XEP-0273) is used).
* | Merge 0.11->trunkMatthew Wild2020-12-151-2/+2
|\|
| * MUC: Fix logic bug causing unnecessary presence to be sent, fixes #1615 ↵Matthew Wild2020-12-151-2/+2
| | | | | | | | (thanks damencho)
* | MUC: Merge mod_muc_occupant_id into a sub-module (thanks pep.!)Matthew Wild2020-11-242-0/+72
| |
* | MUC: Remove XEP-0091: Legacy Delayed DeliveryKim Alvefur2020-10-171-3/+0
| | | | | | | | | | | | | | Why do we still include this? Deprecated in 2007, obsoleted in 2009. Removes redundant timestamp that nobody should be looking at since many years and a redundant copy of the room JID.
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-02 08:02:20 +0000