Exception in Room Config (Invalid value for 'whois')
Issue #47
closed
Exception in Room Config : layer_ce61f985-1d2d-4621-97c2-d416424ead9f rocks.xmpp.core.stanza.StanzaException: <bad-request/> - (type 'cancel': do not retry (the error cannot be remedied)) Invalid value for 'whois' at rocks.xmpp.core.session.XmppSession.query(XmppSession.java:516) at rocks.xmpp.core.session.XmppSession.query(XmppSession.java:462) at rocks.xmpp.extensions.muc.ChatRoom.configure(ChatRoom.java:835)
Comments (7)
-
repo owner
-
repo owner
Is it "participant" maybe? I saw that "muc#roomconfig_allowpm" defines "anyone", "participants", "moderators" and "none" as valid values, while "muc#roomconfig_whois" only defines "anyone", "moderators" and "none" (lacks "participant").
-
repo owner
I have excluded the value "participants" from the "muc#roomconfig_whois" option, since it is not specified by XEP-0045 and I am suspecting this is causing the error.
8fb179a36d1211f48f035477ffad7eafc2cc70dc
Please let me know if you indeed used Role.PARTICIPANT here.
-
In fact I wasn't sending the muc#roomconfig_whois field at all because I hadn't called rolesThatMayDiscoverRealJids on the configuration object. Prosody, the XMPP server I'm talking to, doesn't support room configuration without a whois field and was returning that bad-request error (it accepts only the values 'moderators' and 'anyone')
Now that I'm calling
rolesThatMayDiscoverRealJids(EnumSet.of(Role.MODERATOR, Role.PARTICIPANT, Role.VISITOR)), the form submission stanza sent by Babbler does include a muc#roomconfig_whois field with a value of 'anyone' and Prosody is happy.Looking at the spec, I'm not sure if Prosody should accept a configuration form without muc#roomconfig_whois or if Babbler shouldn't allow submitting a form with that field missing.
-
repo owner
Ok, interesting. To me it seems like this is either a Prosody bug, or a special configuration of the deployment, i.e. a local server policy saying, that this field is mandatory (maybe the server admins want it). XEP-0045 does not require it to be present.
-
repo owner
- marked as major
-
repo owner
- changed status to closed
This was a either a Prosody bug or a deployment policy. => Close
- Log in to comment
Do you know which value is is complaining about? Actually valid values are "anyone", "moderators" or "none". From XEP-0045: The _whois configuration option specifies whether the room is non-anonymous (a value of "anyone"), semi-anonymous (a value of "moderators"), or fully anonmyous (a value of "none", not shown here).
If your server is expecting anything else, it's an server issue (violating the spec).