[OF-179] Allow MUC permissions to be set using groups Created: 10/18/05
Updated:
01/12/16 Resolved: 11/13/14
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Resolved
Openfire
MUC
3.6.4
Type:
Reporter:
Resolution:
Labels:
New Feature
Matt Tucker
Fixed
None
Attachments:
OpenFire_3.8.2_MUCGroupPermissions.patch
179_screenshot.png
Issue Links:
Related to
is related to OF-1040 Banning users from room does not resu... Resolved
is related to OF-174 Add some improvements to the "User Pe... Open
3.10.0
Priority:
Assignee:
Votes:
Major
Tom Evans
32
of-
Description
It should be possible to assign a group permissions for MUC such as membership, moderator,
admin, etc.
Comments
Comment by Brad Mace [ 05/04/07 ]
It would be nice if it was also possible to define whether or not a group's members have voice in
a room by default
Comment by Michael G. [ 08/14/07 ]
Hi, such a feature would be fine, at the moment I have to add all group users by hand to the
MUC room. Would be easier to onlye say group xyz has permissions to enter the room.
Comment by Daryl Herzmann [ 05/28/08 ]
Hi,
I made an initial attempt to generate a patch to implement this feature, but got in over my head
with doubts that such functionality was possible without major code reworking. Any comments
from the devels on if this feature is doable?
daryl
Comment by Eric Rutherford [ 04/29/11 ]
Is there any possible way to breath some life into this issue? Adding a large number of users at
once wouldn't work properly. This would actually need to be LDAP group based. For instance,
if someone new were added to the LDAP group permissions to that group chat would be
updated automatically.
Comment by wroot [ 04/29/11 ]
Eric, you request is even more complex. Though this seem logical. If one is adding a group as
MUC members, then he probably wants for every new member of a group to become member of
this MUC also. I'm afraid this won't be done soon, unless someone will provide a patch for this,
but as Daryl said this will probably need a lot of code reworking.
Comment by Daryl Herzmann [ 02/23/13 ]
unassigning, needs somebody to take it on!
Comment by Jerry Qassar [ 06/06/13 ]
This feels like it is/should be one of the most important remaining outstanding issues in OF for
enterprise users (or even just admins who organize their users into groups). Currently, if you
want to maintain a chatroom that should be open to everyone on a certain team (but not others),
you have to:


set the administrator JIDs explicitly, instead of using the group you've created for them
add every user JID in your group of interest (a waste of time) or set a room password
and skip it (unwieldy).
Comment by John Anderson [ 08/21/13 ]
I just got done with a patch that I believe can act as a workaround for this problem. I don't
believe this will be the final solution implemented, because this way is kind of inefficient. I
haven't done much testing with this patch, but I plan doing more this weekend, so there's no
guarantees. However, for those of you waiting on this patch, I'd appreciate it if you'd apply it
and see if it works for you. Especially if you are using LDAP for your users/groups.
If you go to Group Chat, then select or create a room, then click User Permissions on the left,
you get a screen called "User Permissions" where you can type in a user's JID or short node
name, and then select Owner, Admin, Member, w/e. Then add. Put the name of one of your
LDAP groups in there. You'll see that $groupName@whatever.your.domain gets added under
the appropriate heading. Once that is done, with the patch applied, users who are in that group
will have the access level you assigned that group to, unless they are aslo assigned to the MUC
as their user or with another group with a higher level privilege.
Edit: Somehow, awesomely, evertime I try to copy/paste the patch into this textarea, the lines
get double spaced.
Index: src/java/org/jivesoftware/openfire/muc/spi/LocalMUCRoom.java
===================================================================
--- src/java/org/jivesoftware/openfire/muc/spi/LocalMUCRoom.java
(revision 13668)
+++ src/java/org/jivesoftware/openfire/muc/spi/LocalMUCRoom.java
copy)
@@ -42,6 +42,9 @@
import org.jivesoftware.openfire.XMPPServer;
import org.jivesoftware.openfire.auth.UnauthorizedException;
import org.jivesoftware.openfire.cluster.NodeID;
+import org.jivesoftware.openfire.group.Group;
+import org.jivesoftware.openfire.group.GroupManager;
+import org.jivesoftware.openfire.group.GroupNotFoundException;
import org.jivesoftware.openfire.muc.CannotBeInvitedException;
import org.jivesoftware.openfire.muc.ConflictException;
import org.jivesoftware.openfire.muc.ForbiddenException;
@@ -170,14 +173,14 @@
private long lockedTime;
/**
-
* List of chatroom's owner. The list contains only bare jid.
+
* Set of chatroom's owner. The list contains only bare jid.
*/
-
List<JID> owners = new CopyOnWriteArrayList<JID>();
+
List<JID> owners = new CopyOnWriteArrayList<JID>();
/**
-
* List of chatroom's admin. The list contains only bare jid.
+
* Set of chatroom's admin. The list contains only bare jid.
*/
-
List<JID> admins = new CopyOnWriteArrayList<JID>();
+
List<JID> admins = new CopyOnWriteArrayList<JID>();
(working
/**
* List of chatroom's members. The list contains only bare jid, mapped
to a nickname.
@@ -185,7 +188,7 @@
private ConcurrentMap<JID, String> members = new
ConcurrentHashMap<JID,String>();
/**
* List of chatroom's outcast. The list contains only bare jid of not
allowed users.
+
* Set of chatroom's outcast. The list contains only bare jid of not
allowed users.
*/
private List<JID> outcasts = new CopyOnWriteArrayList<JID>();
@@ -514,6 +517,7 @@
throw new UnauthorizedException();
}
}
+
GroupManager groupManager = GroupManager.getInstance();
LocalMUCRole joinRole = null;
lock.writeLock().lock();
try {
@@ -523,6 +527,19 @@
}
final JID bareJID = user.getAddress().asBareJID();
boolean isOwner = owners.contains(bareJID);
+
if(!isOwner){
+
Iterator<JID> iter = owners.iterator();
+
while(!isOwner && iter.hasNext()){
+
+
try{
JID grpJID = iter.next();
+
Log.debug("Checking to see if "
+ grpJID.getNode() + "can be looked up as a group.");
+
isOwner =
groupManager.getGroup(grpJID.getNode()).isUser(bareJID);
+
Log.debug("It has been looked
up, and user " + bareJID + (isOwner ? " is a" : " is not a") + " member.");
+
}catch(GroupNotFoundException e){
+
message is not a group.");
Log.debug("Lookup from previous
+
}
+
}
+
}
// If the room is locked and this user is not an owner raise a
RoomLocked exception
if (isLocked()) {
if (!isOwner) {
@@ -578,6 +595,70 @@
}
}
+
// Determine if the lists of sysadmins, admins, members and
outcasts contain
+
// a group to which the user is a member.
+
Iterator<JID> iter;
+
Collection<JID> sysadmins = mucService.getSysadmins();
+
boolean isSysadmin = sysadmins.contains(bareJID);
+
if(!isSysadmin){
+
iter = sysadmins.iterator();
+
while(!isSysadmin && iter.hasNext()){
+
+
try{
JID next = iter.next();
+
Log.debug("Checking to see if SysAdmin element
" + next.toBareJID() + " is a group.");
+
Group g =
groupManager.getGroup(next.toBareJID());
+
isSysadmin = g.isUser(bareJID);
+
Log.debug("It has been looked up, and user " +
bareJID + (isSysadmin ? " is a " : " is not a ") + "member.");
+
}catch(GroupNotFoundException e){
+
group.");
Log.debug("Previous SysAdmin element is not a
+
}
+
}
+
}
+
boolean isAdmin = admins.contains(bareJID);
+
if(!isAdmin){
+
iter = admins.iterator();
+
while(!isAdmin && iter.hasNext()){
+
try{
+
JID next = iter.next();
+
Log.debug("Checking to see if admin element "
+ next.getNode() + " is a group.");
+
Group g =
groupManager.getGroup(next.getNode());
+
isAdmin = g.isUser(bareJID);
+
Log.debug("It has been looked up, and user " +
bareJID + (isSysadmin ? " is a " : " is not a ") + "member.");
+
}catch(GroupNotFoundException e){
+
group.");
Log.debug("Previous admin element is not a
+
}
+
+
}
}
+
boolean isMember = members.containsKey(bareJID);
+
if(!isMember){
+
iter = members.keySet().iterator();
+
while(!isMember && iter.hasNext()){
+
try{
+
JID next = iter.next();
+
Log.debug("Checking to see if members element
" + next.getNode() + " is a group.");
+
Group g =
groupManager.getGroup(next.getNode());
+
isMember = g.isUser(bareJID);
+
Log.debug("It has been looked up, and user " +
bareJID + (isSysadmin ? " is a " : " is not a ") + "member.");
+
}catch(GroupNotFoundException e){
+
group.");
Log.debug("Previous member element is not a
+
}
+
}
+
}
+
boolean isOutcast = outcasts.contains(bareJID);
+
if(!isOutcast){
+
iter = outcasts.iterator();
+
while(!isOutcast && iter.hasNext()){
+
+
try{
JID next = iter.next();
+
Log.debug("Checking to see if outcast element
" + next.getNode() + " is a group.");
+
Group g =
groupManager.getGroup(next.getNode());
+
isOutcast = g.isUser(bareJID);
+
Log.debug("It has been looked up, and user " +
bareJID + (isSysadmin ? " is a " : " is not a ") + "member.");
+
}catch(GroupNotFoundException e){
+
group.");
Log.debug("Previous outcast element is not a
+
}
+
+
}
}
// Set the corresponding role based on the user's affiliation
MUCRole.Role role;
MUCRole.Affiliation affiliation;
@@ -586,27 +667,27 @@
role = MUCRole.Role.moderator;
affiliation = MUCRole.Affiliation.owner;
}
-
else if (mucService.getSysadmins().contains(bareJID)) {
+
else if (isSysadmin) {
// The user is a system administrator of the MUC service.
Treat him as an owner
// although he won't appear in the list of owners
role = MUCRole.Role.moderator;
affiliation = MUCRole.Affiliation.owner;
}
-
else if (admins.contains(bareJID)) {
+
else if (isAdmin) {
// The user is an admin. Set the role and affiliation
accordingly.
role = MUCRole.Role.moderator;
affiliation = MUCRole.Affiliation.admin;
}
-
else if (members.containsKey(bareJID)) {
+
else if (isMember) {
// The user is a member. Set the role and affiliation
accordingly.
role = MUCRole.Role.participant;
affiliation = MUCRole.Affiliation.member;
}
-
else if (outcasts.contains(bareJID)) {
+
else if (isOutcast) {
// The user is an outcast. Raise a "Forbidden" exception.
throw new ForbiddenException();
}
-
else {
+
else{
// The user has no affiliation (i.e. NONE). Set the role
accordingly.
if (isMembersOnly()) {
// The room is members-only and the user is not a
member. Raise a
Comment by JOhn Douglas [ 08/22/13 ]
thought I'd try the patch but the text cuts off in mid line leaving several hanging if-then-else
blocks. SO not even starting a test.
Please set up full patch or check it in.
JD
Comment by Daryl Herzmann [ 08/22/13 ]
John Anderson, you should have permissions now to attach files to tickets. Please attach your
patch
Comment by John Anderson [ 08/26/13 ]
Try this attached file with patchlevel 1. On unix machines it might be advisable to dos2unix this
file before trying to apply.
I've had the chance to do some testing, and these changes 'Work For Me'. However, in my use
case I'm using LDAP user & groups, allow only MUCs defined through the admin console, and
assign permissions to MUCs through the admin console. I'm not entirely sure if these changes
will work with user created MUCs or other circumstance outside of my use case.
Also I should note that this patch should apply to version 3.8.2 from
http://www.igniterealtime.org/downloads/downloadlanding.jsp?file=openfire/openfire_src_3_8_2.tar.gz .
Test instructions if you are already using 3.8.2.
1. Download sources and patch from above links.
2. Unpack the 3.8.2 source archive, and CD into the top level directory of the unpacked
sources.
3. Apply the patch
4. patch -Np1 < /path/to/downloaded/patch
1. cd build && ant
5. Replace existing installation's openfire.jar with new one created by build.
1. cp ../target/opefire/lib/opefire.jar /path/to/openfire/installation/jardir
6. Restart Openfire
Comment by John Anderson [ 09/03/13 ]
Has anyone applied the patch successfully? Does it seem to be working as intended?
Comment by Jonas Blomqvist [ 09/18/13 ]
This patch seems to work, we are not using LDAP, only the built-in groups that are
automatically populated by our forumsoftware
Comment by Jonas Blomqvist [ 09/19/13 ]
Just my 5 cents, would it be hard to change it so that this patch would use a fake subdomain for
groups? ie groupname@group.domain.name ? just to keep things tidy and to guarantee that
there never is a user and a group with the same name ?
Comment by John Anderson [ 09/19/13 ]
I'm don't think it would be too difficult. I'm more concerned with overall architecture of the
product though. I'm not an official OpenFire developer or anything, and this is the first
modification I've made to this product. I've been using it for a few months, and it didn't do
something I needed it to do, so I made a small change, and that's about all I know about the
subject. I'd like for the group permissions functionality to be included in the mainline product at
some point, but I don't know what would be the best practice solution for that.
Any suggestions from maintainers on the subject of ensuring group & user JIDs don't collide?
Comment by Barney Garrett [ 09/25/13 ]
Just want to add ... I've just implemented this ... I had to apply the patch by had as the patch file
wouldn't work on my system for some reason.
We are using the built in groups and it worked great first time ... Many thanks ... I've been
meaning to do this for ages now.
PS anyone else note the broken affiliation and roles code ? Owner and Admin are made
Moderator/Owners and Members are Moderator/Admin. According to the spec Admins should
be Moderator/Admin and Members should be Participant/Member
Comment by John Anderson [ 09/30/13 ]
Barney Garrett: Are the broken roles a result of my patch? I haven't looked yet, but it's more
than possible I made a mistake in there. If so, I'd like to fix it. Also, do you still have the .rej
files from the patch where it didn't apply correctly? I'd like to know what is up with that as well.
It applied cleanly last time I downloaded a fresh copy of the release source tarball so I'm curious
to see what caused the problems.
I'm glad to hear from you and Jonas confirming that the patch is mostly working both in LDAP
and internal groups. I'd like to see these changes, perhaps not my implementation of these
changes, but the result of these changes, be put in the mainline codebase. So that adding
permissions to MUCs by group is supported by the OpenFire project.
Comment by Barney Garrett [ 10/02/13 ]
I don't have the rej files I'm afraid ... everything failed I do remember that much though.
and the roles aren't broken by your code ... it looks to be deliberate since the comments line up
with what the code does, I just think it is wrong Essentially everyone who is made a member
of a room has some level of admin rights in it.
Comment by João Carmo Pereira [ 10/15/13 ]
Hi, i did a new openfire.jar using your patch, but now i don't know how to assign a group to a
muc.
i have a internal group called "testgroup". when i add the JID as member using
testgroup@mydomain, i try to log into a channel with a user, but with no sucess.
what i'm doing wrong?
Comment by John Anderson [ 03/17/14 ]
Seeing as how this issue is still open, I suppose this type of functionality isn't in mainline yet. So
over the course of the next month or so, I was thinking about updating this patch to current GA
version 3.9.1.
Then I had an idea:
Currently I dig through the logic that allows users into MUCs. The mainline logic checks to see
if the user is allowed to be in the MUC, and what kind of role the user should have inside the
MUC. So I simply fetch the user's group, and run the same checks again over the user's array of
groups. Well, something very similar to that.
However, what if i were to forget about all that, and write an OpenFire plugin. This plugin
would be a scheduled task, that would run frequently. Or perhaps a task that was triggered by
the addition, deletion, or modification of a MUC, group, user, role, or any kind of access related
item. Once triggered, this task would iterate over the existing MUCs, and determine which
MUC permission objects were groups. Then it would iterate over the users in that group, and
add the JIDs of that group to the appropriate permission slot of the MUC.
This is a lot more coding, and you'd end up with the group JID, as well as every member of the
group's JID in the MUC's permission list. However, it should work so that if you assign a
member to a group, and that group has permissions in a MUC, then the user gets added to the
MUC. If you remove a user from a group, then the job would remove the user's JID from the
MUC's permission list.
At least this way we aren't mucking about with core code, just writing a job that manipulates the
permissions. I am concerned that this might have issues with LDAP though, as I'm pretty sure
OpenFire caches LDAP data, and won't know about any changes to users or groups until those
things expire from cache. I just don't know enough about how it works internally.
Comment by Tom Evans [ 11/06/14 ]
Working on this capability now; see the attached screenshot for a preview of the proposed UI.
Comment by John Anderson [ 11/06/14 ]
Thank you for taking a look at this. I never quite figured out the plugin idea I had in mind and
eventually I had to move on to other tasks. I had always hoped to come back and revisit this
though.
Comment by Tom Evans [ 11/10/14 ]
PR submitted and ready for review: https://github.com/igniterealtime/Openfire/pull/100
Comment by wroot [ 11/13/14 ]
Do we need to change the name to Access Controls (the name is wonky)? What's wrong with
User Permissions? User is a member of a group, so it is still about user permissions even if you
can add a group of users to some role. Also it says "Room Affilations" on the page itself, so
there is a disconnect between menu name and the title in there. Affilations is probably a more
suitable word in this case, but many non-english speakers would not know it. Permissions is a
more common name.
Other than that, it works. Though i don't really like that window with a scrollbar (which will get
clunky with hundreds of groups), but i don't know of a better solution. Paged list of groups
would also be clunky and having to type group names also inconvenient.
Comment by Tom Evans [ 11/13/14 ]
Happy to change "Access Controls" to "Permissions" in the English version. Note also that there
will be some additional work needed at some point to update the other (non-English)
localizations updated. Assistance from the community is welcome for that effort.
This is now feature-complete and will be available in the nightly build starting tomorrow.
Comment by wroot [ 11/13/14 ]
Hm. As you have marked this as resolved, there will be no changes? At least the menu name
and the title on the page should be the same, to be consistent.
Comment by Tom Evans [ 11/13/14 ]
We can definitely incorporate changes, feel free to continue posting here. I just wanted to signal
to the watchers that this feature is functionally complete and ready for review and testing. It will
also be included in the upcoming release.
Generated at Mon Mar 07 00:01:50 CST 2016 using JIRA 7.0.10#70120sha1:37e3d7a6fc4d580639533e7f7c232c925e554a6a.