Shouldn't allow subject change, when it is forbidden in room settings
Description
Environment
Activity
wroot January 10, 2016 at 8:19 PM
I have tested this with the latest build and it works. Though the wording is a bit confusing. One would think that strict should mean more restricting (not allowing forbidden actions). But in this case strict means it will allow subject changes by not standard clients (strict meaning working strictly by standards). So one has to set it to "false" to forbid changing of room's topic by any client.
Tom Evans January 4, 2016 at 8:20 PMEdited
Per discussion in the linked PR, we have opted to implement the server using a strict/conforming policy with respect to the XEP-0045 specifications. However, we have also added a new configuration property that can be used for installations that want to support older/non-conforming clients like Exodus:
xmpp.muc.subject.change.strict = false
Tom Evans January 4, 2016 at 8:19 PM
OK, I took another stab at this (PR #478), and we appear to be getting the expected results from Pidgin, Psi, and Exodus.
Tom Evans December 22, 2015 at 10:04 PM
Yes, the specification is unfortunately vague when it comes to the responsibility for MUC room subject changes (client vs. server):
The various client(s) must send subject changes as specially formulated MUC messages, and must further interpret certain messages in the stream as subject change events;
The server must watch the message stream to detect when a subject change is being requested, and reject any unauthorized subject change attempts;
The server must also manage the MUC history feature, which requires the server to replay some small portion of recent message history, followed by a message representing the most recent subject change (regardless of when it may have occurred in the history). Thus the spec includes this guidance:
Note well that this means the room subject (and changes to the room subject prior to the current subject) are not part of the discussion history.The core XMPP specification precedes/supersedes the MUC specification, thus this additional guidance from the MUC spec:
Note: In accordance with the core definition of XML stanzas, any message can contain a <subject/> element; only a message that contains a <subject/> but no <body/> element shall be considered a subject change for MUC purposes.The various server and client implementations do not all agree on these conventions.
This ambiguity leads to a bit of a Catch-22 where clients and servers disagree about which messages in the stream are actual (valid) subject changes.
I am proposing a workaround whereby the server will be lenient (with respect to the MUC specification) when detecting inbound subject change requests, and strict (conforming) when (re-)distributing these messages outbound to the various MUC clients. The intent is to use the server to normalize the subject change behavior among the various client implementations.
wroot December 22, 2015 at 4:42 AM
Wait. Are you saying that it's the client (say Spark in this case) thinks that this is a legitimate subject change? I was under impression that room's subject should be controlled and set solely by server alone. If that's the case, i'm not sure what you going to do about it. I can close this ticket and open new one for Spark. Or you will somehow strip those messages out of <body> element when receiving in a MUC, so those clients won't be confused?
Man, after finding out such things (and many other confusing logic) i can see why xmpp is dying out..
reported at: http://www.igniterealtime.org/community/message/172213#172213
When i started testing this i have discovered that the permissions and options are totally broken. Maybe there are more bugs in there, but i dont have time to find them all. User has reported that users were able to change the topic to a blank only. He was testing with Spark and older Openfire. I was testing with Exodus and Openfire 3.5.1. I have created a room like he described and put my Exodus user as a Member. I was able to change room's topic to whatever i wanted and this was preserved after leaving and joining again. And after logging in with Spark user i was seeing the changed topic. I have made that room not Members only and removed Exodus user from members list. Same effect, doing to subject any changes and them are saved.
Another issue, that i cant restore old topic from the Admin Console by simply pressing Save Changes. Well, i dont change anything in forms, but shouldnt it rewrite all the settings in the db after clicking that button? Now i have to change topic to slightly different. Press Save, then change topic back and press Save again.
I think this is really critical if i'm not missing something.