Hi List,

the attached patch takes a stab at fixing issue #345 [1]. I'm new to
XMPP (and obviously Prosody) and not sure if this is the way to fix the
issue, but if it's not, any pointers would be appreciated.

That being said, a couple of reservations about the patch:

- In line 40 of the patch, I create a temporary variable to find out
whether the loop was run at least once. Is there a different mechanic in
Lua to do this nicer, or is this the way to go?

- Regarding the error handling in lines 49, 55 and in-tree 801 (the last
one is not in the patch because I did no changes there): Is it okay to
just send multiple error messages or should they be collected somehow
and sent as batch after the complete stanza was processed? I could find
nothing about this in either the MUC XEP, nor in the three (or so) base
RFCs of XMPP.

Let me know if you'd like me to make any changes to this patch.

If this patch gets accepted (with possible modifications), I can easily
cook up one just like it for trunk as well. I already saw that the muc
code has changed quite a lot, but in regards to this patch it's only for
the better.

Best regards
Lennart Sauerbeck

[1] https://prosody.im/issues/issue/345

-- 
You received this message because you are subscribed to the Google Groups 
"prosody-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prosody-dev+unsubscr...@googlegroups.com.
To post to this group, send email to prosody-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/prosody-dev.
For more options, visit https://groups.google.com/d/optout.
# HG changeset patch
# User Lennart Sauerbeck <de...@lennart.sauerbeck.org>
# Date 1489859248 -3600
#      Sat Mar 18 18:47:28 2017 +0100
# Node ID 437551dab8c8f0842ba266e0beae3c06c5f19330
# Parent  1c6a0760630952c8f053ad4135dc0d9996f4ae90
muc: Allow clients to change multiple affiliations or roles at once (#345)

According to XEP-0045 sections 9.2, 9.5 and 9.8 affiliation lists and role
lists should allow mass-modification. Prosody however would just use the
first entry of the list and ignore the rest. This is fixed by introducing
a `for` loop to `set` stanzas of the respective `muc#admin` namespace.

In order for this loop to work, the error handling was changed a little.
Prosody no longer returns after the first error. Instead, an error reply
is sent for each malformed or otherwise wrong entry, but the loop keeps
going over the other entries. This may lead to multiple error messages
being sent for one client request. A notable exception from this is when
the XML Schema for `muc#admin` requests is violated. In that case the loop
is aborted with an error message to the client.

The change is a bit bigger than that in order to have the loop only for
`set` stanzas without changing the behaviour of the `get` stanzas. This is
now more in line with trunk, where there are separate methods for each
stanza type.

References: #345

diff -r 1c6a07606309 -r 437551dab8c8 plugins/muc/muc.lib.lua
--- a/plugins/muc/muc.lib.lua	Thu Mar 09 01:20:59 2017 +0100
+++ b/plugins/muc/muc.lib.lua	Sat Mar 18 18:47:28 2017 +0100
@@ -772,15 +772,17 @@
 			local affiliation = self:get_affiliation(actor);
 			local current_nick = self._jid_nick[actor];
 			local role = current_nick and self._occupants[current_nick].role or self:get_default_role(affiliation);
-			local item = stanza.tags[1].tags[1];
-			if item and item.name == "item" then
-				if type == "set" then
+			if type == "set" then
+				local at_least_one_item_provided = false;
+
+				for item in stanza.tags[1]:childtags("item") do
+					at_least_one_item_provided = true;
+
 					local callback = function() origin.send(st.reply(stanza)); end
 					if item.attr.jid then -- Validate provided JID
 						item.attr.jid = jid_prep(item.attr.jid);
 						if not item.attr.jid then
 							origin.send(st.error_reply(stanza, "modify", "jid-malformed"));
-							return;
 						end
 					end
 					if not item.attr.jid and item.attr.nick then -- COMPAT Workaround for Miranda sending 'nick' instead of 'jid' when changing affiliation
@@ -799,8 +801,17 @@
 						if not success then origin.send(st.error_reply(stanza, errtype, err)); end
 					else
 						origin.send(st.error_reply(stanza, "cancel", "bad-request"));
+						return;
 					end
-				elseif type == "get" then
+				end
+
+				if not at_least_one_item_provided then
+					origin.send(st.error_reply(stanza, "cancel", "bad-request"));
+					return;
+				end
+			elseif type == "get" then
+				local item = stanza.tags[1].tags[1];
+				if item and item.name == "item" then
 					local _aff = item.attr.affiliation;
 					local _rol = item.attr.role;
 					if _aff and not _rol then
@@ -838,9 +849,9 @@
 					else
 						origin.send(st.error_reply(stanza, "cancel", "bad-request"));
 					end
+				else
+					origin.send(st.error_reply(stanza, "cancel", "bad-request"));
 				end
-			elseif type == "set" or type == "get" then
-				origin.send(st.error_reply(stanza, "cancel", "bad-request"));
 			end
 		elseif xmlns == "http://jabber.org/protocol/muc#owner"; and (type == "get" or type == "set") and stanza.tags[1].name == "query" then
 			if self:get_affiliation(stanza.attr.from) ~= "owner" then

Reply via email to