I’ve been lurking on the forums for a while, but this is my first post! I apologize if this is an issue that has popped up before.
So, I am running a server in which some users have access to some channels, but not others, this is for security. I use groups to gate access to channels. For example, I have a general channel and a management channel. Then two groups to go with that which have the same names (general and management). To access the general channel, you have to be a member of the general group. The management group has access to the management channel, and is also set as a moderator of the general channel.
The problem I have is this - When a new user registers with the server, and an admin assigns the appropriate groups to them, the user is unable to join the channel which uses that group for access until the server restarts. The users always receive the message that they do not have permission to access the channel.
Like I said, this is fixed by restarting the server.
I am using 3.10 server version and 2.7 of the spark client. The VM is using CentOS 32bit.
Thanks for this interesting bug report! I assume you are exercising the new MUC room access control lists by group functionality? Otherwise, I am unsure what you mean by ‘channels’?
Yes, sorry for the confusion, channel = room.
Curious if you are using the default Groups provider, or perhaps you are using LDAP for your installation? It seems you are experiencing a caching problem, and we have seen this type of caching behavior with LDAP in other parts of the product.
The server was set up with the default groups provider. If there is any other information I can provide, let me know!
I am unable to reproduce this issue with the following procedure. Can you try this procedure as well?
- Created users loser1 and loser2
- Created group losergroup and added loser1 to the group
- Created groupchat loserroom and verified that both loser1 and loser2 could access it
- Changed loserroom to members only and set a member ACL for the losergroup
- loser1 could join the room, loser2 could not
- Added loser2 to losergroup
- loser2 could now join the room
I’m having similar issues:
I’m using the Atlasssian Crowd authentication drivers, and I’m experiencing the following:
I have a room (testroom1), which is set to members-only and has a group (testgroup1) set as room members.
I create a user (testuser1) and add that user to testgroup1 in crowd.
Once the group membership gets pulled through (i can see in openfire that the user is a member of testgroup1) i login as that user and attempt to join testroom1. I get a “407: Registration Required” error. If i restart the openfire server, the user can join the room. I’ve also found that if i remove testgroup1 from the room’s ACL and then re-add the group, the user will get an invite to the room and be able to join.
I’ve tried leaving it quite a while between adding the user to the group and attempting to join, and this results in the same issue. The issue is starting to become quite a headache for me, as we’re supposed to be migrating our 1500+ users to this new installation very soon.
The problem seems to arise, for me at least, when the group ACL is already applied to a room and then a user is added to that group. If i remove and re-add the group to the ACL, then the users get access, hence why this repro wouldn’t work.
I registered just to respond to this. I am encountering this for openfire 3.10.2 (the deb for Ubuntu 14.04 LTS).
Create new conference (testmuc)
create new room (testroom) on testmuc
create new group (testgroup)
apply testgroup group to testroom permissions as “member”
Create new user (testuser)
Add testuser to testgroup
Set testroom to “make room members only”
testuser will connect to the server, but will receive “407: Registration required” response.
Restart the server
testuser will reconnect and be able to join the room.
Anything I can do to help resolve this would be nice. I really like Openfire but this is a dealbreaker for how large some of my groups are.
Any news on this? Bug is getting more and more annoying, since we have different groups changing ond daily basis.
I “think” 3.10.3 fixed this? I had good results with testing earlier. Will report back monday as I’m adding 80 people to it then.
A patch for this did go into 3.10.3, so hopefully it is. [OF-921] MUC Group ACLs are not updated when users join a group - Jive Software Open Source