I have a user that is a member of a persistent, members-only chat room. When I join the room with this user, I can get the room members list without issue. However, when he’s not joined I get a “not-authorized” error back. Here’s the packet I’m sending:
This is generated with the Smack API’s MultiUserChat.getMembers() method.
And here’s the response I get back from Openfire:
I was reading over the XEP-0045 (Multi-User Chat) and in section 9.5 (just under example 119) it says “A service SHOULD also allow any member to retrieve the member list even if not yet an occupant”.
In org.jivesoftware.openfire.muc.spi.LocalMUCUser, around line 348 has the following:
MUCRole role = roles.get(group);
if (role == null) {
sendErrorPacket(packet, PacketError.Condition.not_authorized);
}
From what I can tell, the roles get assigned only upon entering a room, all triggered by LocalMUCRoom.joinRoom method (which creates a LocalMUCRole, which then adds itself to the LocalMUCUser).
Unless I’m missing something here, it doesn’t appear that Openfire does support this operation.
So I guess my next question is: can support be added to allow room members to query for the room member list when not an occupant? If that seems like something you’d like to support, I’d be happy to raise a ticket and maybe even take a first crack at the code.
Does anyone have an opinion on this? … whether allowing a member of a room to be able to see the list of members when not joined (i.e. not an occupant) is a feature you’d like to add to openfire?
I agree - we certainly want Openfire to exhibit standard behavior for an XMPP Server.
This is what XEP-0045 has to say (taken from section 9.5 just under example 119): “A service SHOULD also allow any member to retrieve the member list even if not yet an occupant”.
I’m assuming that since it’s using the word “SHOULD”, the spec isn’t very firm on this - but does seem to at least be a recommendation.
Yeah, i think they usually use “MUST” if something have to be done As specs are not forbidding this, then you can do this. Though, as you can see there are not many requests for this here. Anyway, if you’ll decide to tackle with this, i can create a New Feature or Improvement ticket for this in JIRA
Makes sense - sure, go ahead and create the ticket. My only concern is that while looking through the code, it looked like it may require some re-work of the muc “plumbing”, but I’ll see what I can do.