| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This avoids doing performing unnecessary work in the case of visitors joining
a MUC, no functionality changes are intended.
|
|
|
|
|
|
|
|
|
|
| |
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)."
|
| |
|
| |
|
|
|
|
|
| |
Including the payload of the stanza that caused the error is optional
and we're generally not doing it anywhere else.
|
|
|
|
|
| |
Mistake introduced in cbe524ed1a6a. Removing because this is a query to
the bare JID where the error origin matches the resulting stanza 'from'.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
.affiliation
It appears nothing currently uses this field in prosody or prosody-modules
|
| |
|
|
|
|
| |
...and fixing the logic bug that broke everything in the previous commit.
|
|
|
|
| |
data
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Fixes https://prosody.im/security/advisory_20210722/
Backs out 4d7b925652d9
|
| |
| |
| |
| |
| | |
Optimizes away all the processing on every message in case the
end-result is zero history.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
Should help inform on whether the cache size should be increased.
|
| | |
|
| |
| |
| |
| | |
Also test for self-probes
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
|\| |
|
| |
| |
| |
| | |
(thanks damencho)
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\| |
|
| |
| |
| |
| | |
#1595) (thanks lessthan3)
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Thanks pep. and lovetox
XEP-0045 §6.4:
> any field defined for the muc\#roomconfig FORM_TYPE can be included in
> the extended service discovery fields
Probably happened because the same mistake is in #1155
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Behavior with turning empty name into localpart was originally introduced
in 711eb5bf94b4
This has caused some problems for clients, making it difficult to
differentiate between a room actually named like the localpart from a
room without a name.
Breaking:
The function signature of the :get_name() method changes from always
returning a string to optional string.
|
| |
| |
| |
| | |
Updates #1533
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
If nickname enforcement is enabled this would otherwise let you bypass
the join check in muc.lib by registering an invalid nickname and then
joining with any nickname, letting register.lib change it to the invalid
registered nick.
|
| |
| |
| |
| |
| |
| | |
This is the subset of mod_mam rules I believe makes sense in MUC.
Note that mod_muc_mam does not have its own rules, but uses these.
|
|\| |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
presence
|
| |
| |
| |
| | |
occupant presence
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This gives service admins a way to set an arbitrary affiliation in any
room. Enables various administrative use cases such as room ownership
reassignment or recovery.
Reduces the need for the admins-as-owners feature, as this can be used
by admins to make themselves owner in any room when needed, instead of
being owners all the time.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Based on the currently-deferred XEP-0317. The protocol differs
a little (because XEP-0317 is incomplete), therefore currently
we use a custom namespace.
The plan is to update and finish XEP-0317.
|
| | |
|