MUC change affiliation/role - admin IQ item processing bug


Hello Openfire development:

There seems to be a bug in Openfire (v3.7.1) when processing affiliation/role change. When a room administrator sends the following IQ affiliation/role change stanza, with multiple items, the server returns a BAD_REQUEST 400 response.

<iq from='admin@mydomain/myresource' to='myroom@mydomain' type='set' id='affil_1' xmlns='jabber:client'>
<query xmlns='''>
<item jid='user@mydomain/myresource' affiliation='none'/>
<item nick='mynick' role='participant'>

The code which causes this to happen is on line 213 in IQAdminHandler class's handleItemsElement method:

boolean hasAffiliation = ((Element) itemsList.get(0)).attributeValue("affiliation") != null;

The handleItemsElement method loops through each item and checks for role affiliation changes, but the code only checks the first item for an affiliation attribute (above) and in turn falsely reports that the second item has an affiliation (hasAffiliation == true) causing a 400 response.

If the hasAffiliation assignment is moved inside the loop to line 223 and changed to below the error is fixed:

boolean hasAffiliation = item.attributeValue("affiliation") != null;




Tom Evans
April 28, 2014, 4:55 PM

Check for the affiliation attribute on each item in the stanza.

Tom Evans
April 28, 2014, 4:29 PM

The code has changed a bit since the issue was reported, but I believe the proposed fix is still valid. I will apply a patch accordingly.

Daryl Herzmann
April 27, 2014, 6:24 PM

Assigning to Tom for his opinion on the suggested change.

Daryl Herzmann
February 13, 2014, 10:01 PM

Is this issue still happening on a current release (3.9.1)?

Guus der Kinderen
February 6, 2013, 7:57 PM

Removing the 'fix version' for all unresolved issues that were scheduled for version 7.8.2. We're releasing this version today - the remaining issues should be rescheduled later.

Your pinned fields
Click on the next to a field label to start pinning.


Tom Evans


Daryl Herzmann