Currently Openfire is not letting a user to get list of room's occupants if that user is not yet an occupant of that room. Though specs say a service should allow that.
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 not sure this is actually resolved, from what I can tell there is still an error preventing Openfire from returning a member-list from a member-only MUC when the query for the member-list is made before the user has joined the room. RawToast, are you sure Openfire supports the retrieval of member list from room members who have not yet joined the room?
I'm currently running the latest build of Openfire (3.9.3) and I've created a member-only MUC, added two JIDs to the member list, one admin and one member. If I send the following stanza from a JID on the member list
<body rid='551802513' xmlns='http://jabber.org/protocol/httpbind' sid='42731cc7'>
<iq from='t1@server-pc/42731cc7' id='0.38287348952144384' firstname.lastname@example.org' type='get' xmlns='jabber:client'>
Openfire responds with
<iq xmlns="jabber:client" type="error" id="0.38287348952144384" from="email@example.com" to="t1@server-pc/42731cc7">
<error code="401" type="auth">
even though the user who requested the information has been added to the member-list as shown on the Openfire admin console. Is there any work-around for this?
Will reopen and assign to CSH to see what he thinks
Had a look at this. The problem is in LocalMUCUser#process, which returns the error, if the sender is not an occupant. Tried to rectify this, but figured out, that it would require major changes to the MUC logic, because the IQAdminHandler as well as the IQOwnerHandler all require a MUCRole instance (aka occupant).
=> Seems like you can only make admin actions while you are in the room, which is not good.
Hi CSH, are you still looking into this?
Currently not. Requires too many major changes to the MUC logic.