群组成员调用getMembers()获取成员列表时触发403 forbidden-auth权限拒绝

I’ve run into similar XMPP MUC permission issues before, and based on your setup and the XEP-045 spec you referenced, here are the key things to check:

• Verify your room config is actually applied and persisted
  Even though you’ve set muc#roomconfig_getmemberlist: [moderator, participants, visitor], some XMPP servers (like Openfire or Prosody) might require a room restart or server reload for the change to take effect. Additionally, double-check that the config was saved correctly by fetching the room’s owner configuration form (you can send an IQ like this: iq type='get' to='room@conference.yourdomain.com' id='config-check'><query xmlns='http://jabber.org/protocol/muc#owner'/></iq>) and confirming the muc#roomconfig_getmemberlist value matches your intended setting.

• Don’t mix up "Member" vs "Participant" roles
  XEP-045 uses specific terminology here: you said the user is a "group member" (a registered room member who can join the room), but your config grants access to participants—which refers to users currently active in the room. If the user is a registered member but hasn’t joined the room (so they’re not an active occupant/participant), the server might block the request. Make sure the user is successfully joined to the room before calling getMembers().

• Check for server-wide permission overrides
  Some servers have global MUC settings that can override room-level configurations. For example, Openfire has a system property xmpp.muc.get.memberlist.allowed.roles that might restrict member list access to moderators only by default, even if your room config says otherwise. Dig into your server’s global MUC admin settings to ensure there’s no conflicting rule here.

• Validate the request’s context and JID format
  Ensure you’re making the getMembers() request using the user’s full resource JID (e.g., user@yourdomain.com/laptop) instead of a bare JID. MUC permissions are often tied to the active occupant’s session resource, so using a bare JID might cause the server to reject the request. Also, confirm the request is coming from the user’s active online session—offline requests typically won’t work for MUC operations that require occupant context.

As you noted in the XEP-045 spec:

A service SHOULD also return the member list to any occupant in a members-only room, even if the occupant is not a moderator.

The critical word here is occupant—the user must be actively present in the room, not just a registered member. That’s often the missing piece in these cases.

Start with confirming the user is an active room participant, then work through verifying your room and server configs. That should help narrow down the 403 error.

内容的提问来源于stack exchange，提问作者user2934930