As noted, a service (more precisely, a properly-configured room) MAY discard some or all extended namespaces attached to and < presence/> stanzas that are intended for reflection from the sender through the room to all of the room occupants. If the room does so, it SHOULD enable senders to discover the list of allowable extensions by sending a disco#info query to the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic', returning one element for each namespace supported in the result. If the room does not allow any extended namespaces, it MUST return an empty query as specified in XEP-0030.
Artur Hefczyc commented 1 decade ago
I think the first, simplified version could be just a switch - remove extra payload/do not remove without even specifying what the extra payload is. This should be fairly easy to implement and would solve most of the user's problems with this function.
configuration options. muc-allow-all-namespaces defaults to false, preserving current behavior, and may be set to true to simply pass all optional muc traffic. muc-allowed-namespaces can be set to an array of strings representing namespaces which are allowed. This has no effect if muc-allow-all-namespaces is true, because all namespaces will be passed anyway.
I wasn't able to test muc-allowed-namespaces because I couldn't find documentation on setting a string array in the configuration file, just S for string.
patch is against muc package root.
Bjorn Roche commented 1 decade ago
ah, it's lowercase s for string array. I will give it a shot.
Bjorn Roche commented 1 decade ago
ah, it's lowercase s for string array. I will give it a shot.
Bjorn Roche commented 1 decade ago
I had trouble debugging muc-allowed-namespaces for some reason nothing ended up in the logs. I did manage to see one bug visually, and here is an improved patch, but it still doesn't seem to work, so something else is still wrong.
Make the list of allowed namespaces in MUC messages configurable
http://xmpp.org/extensions/xep-0045.html#impl-service-traffic