MUC nickname overwrite

On our jabber server we enforce users to have specific nicknames in MUCs (using an authentication system to attach titles to their name).

Example: The user peter@example.com needs to join the muc public@conference.example.com with nick “Peter (Director)” or he wont be accepted.

Using smack 4.1.0-rc1 on android, the MUC functionality works fine when the user sets the nick to exactly what we expect from that user. Sweet.

But in case the user puts in a wrong nickname (e.g. “peter”) when joining the MUC, smacks throws “XMPPError: forbidden - cancel”.

Which is correct behavior, but the experience delivered by Pidgin is way smoother, it automatically discovers the correct nickname and consequently uses that.

I can manually do that by sending a presence available to the MUC, wait for the response and use the from field to determine the correct nickname, then use MultiUserChat to join (again) with the correct nickname.

Presence p = new Presence(Presence.Type.available);

p.setTo("publicd@conference.example.com/peter");

p.setPriority(1);

con.sendPacket§;

I think the code in MultiUserChat should instead of relying on the hardcoded nick:

PacketFilter responseFilter = new AndFilter(FromMatchesFilter.createFull(room + “/” + nickname), new PacketTypeFilter(Presence.class));

should try to set up filters on the nickname which has been acknowledged by the server.

I am not sure why I once saw “XMPPError: forbidden - cancel”, most of the time I get

org.jivesoftware.smack.SmackException$NoResponseException: No response received within packet reply timeout. Timeout was 60000ms (~60s)

as there is no match in MultIUserChat for any messages.

I agree. What you describe is valid behavior as per XEP-0045.

XEP-0045: Multi-User Chat

(around Example 22-23)

PacketFilter responseFilter = new AndFilter(FromMatchesFilter.createFull(room + “/” + nickname), new PacketTypeFilter(Presence.class));
This is wrong or at least incomplete and fragile (as in your use case). The packet filter should match the status code 110 OR 210 OR nickname. The only problem I see is if there’s already a nickname in the room which matches your requested nickname the join method would return before you have actually joined.

Interesting. I tried XEP-0045: Multi-User Chat but unfortunately my server does not support that.

Thanks for reporting. SMACK-646

ty. You could quote that as well in your ticket (also from 7.2.3):

If the user has connected using a MUC client (as indicated on joining the room by inclusino of the MUC extension), then the service MUST allow the client to enter the room, modify the nick in accordance with the lockdown policy, and include a status code of “210” in the presence broadcast that it sends to the new occupant.

That sounds reasonable. Thanks CSH.

Done, thanks for pointing this out.

110 OR 210 OR nickname
Hmm I think it’s either “nickname stays the same” or “nickname changed and 210”, which would yield a filter like

From with full JID (incl. nickname) OR (From with bare JID, i.e. room JID AND status 210)

But ultimately I think the filter should be just based on the presence stanza ID, since it appears to be stable. See XEP-45 7.2.2 Example 20



and the self presence found in example 24







then we can base the “has nick been modified by service” logic on the stanza the filter matches.

But ultimately I think the filter should be just based on the presence stanza ID, since it appears to be stable.

I think we had this issue once already.

XEP-0045 says:

For tracking purposes, the room might also reflect the original ‘id’ value if provided in the presence stanza sent by the user.

This doesn’t feel stable enough for me.

And yes, check for 110 is probably not needed.

This doesn’t feel stable enough for me.
Right, the “might” makes it necessary to not rely on a stable stanza id here. Thanks for pointing this out.