Thanks, I'm getting a better idea of how that works now. What they want is to have the database hold that the group was automtically generated (IE a column in rostergroups called AutoGen or ReadOnly) and if the column says that group for that user was automatically created, then the user cannot edit it.
What I'm thinking needs done is the database be modified to have that new coulumn. done. The server needs to be able to tell the client that the group is read-only. How to do this escapes me still. The client (Java applet) would block user attempts to modify groups that are read only. I have the changes made to treat MS- prefixes as read-only, I just need to rewrite a method that returns true/false if the user can edit the group. Mainly its the server part that I'm not sure what changes need done where, and I haven't found any documentation that says what is done where in the server source :P *************************************************** Michael Moore ([EMAIL PROTECTED]) (304) 264-2652 Team CGCentral United States Coast Guard Operations Systems Center *************************************************** -----Original Message----- From: Eli Burke [mailto:[EMAIL PROTECTED] Sent: Thursday, September 11, 2003 2:01 PM To: [EMAIL PROTECTED] Subject: RE: [JDEV] Auto roster population/lock some groups Michael, Our situation was not the same but had similar elements, so perhaps this will help you. We had to set up automatic roster population, and then lock clients down so that they could not send messages to users not in their roster (or add/edit/delete new users or groups). The eventual solution was to modify both the client and the server. The client was modified to make for a better "user experience" but the server was modified to prevent the actions entirely. If a user was to use a different client, it might behave strangely, but the server prevents any circumvention of the policy. So, it seems to me you basically have two choices: modify the "roster-add-2" query in xdb_sql.xml so that it rejects or ignores groups that start with "MS-" (I'm not entirely sure how this will behave but it is easy enough to test) or modify jabberd. A cursory look suggests that jsm/modules/mod_group.c in mod_groups_roster_insert() would be a good place to start, though it has been a while and I can't remember if that bit gets called when xdb_sql is running. For the curious, in order to disable ability for users to send IMs or add users not already in their roster, we added the following code to jsm/deliver.c, approx line 158 prior to calling js_user() [Note: NS_ROSTERCHECKis defined as jabber:iq:rostercheck] /* if this is a message packet, make sure the sender is * allowed to send a message to the receiver */ if (jp && jp->type == JPACKET_MESSAGE) { int found = 0; xmlnode x, cur; /* query for the allowed user roster */ if (NULL != (x = xdb_get(si->xc, p->id, NS_ROSTERCHECK))) { /* loop through all names returned to make sure we can send */ for(cur = xmlnode_get_firstchild(x); cur != NULL; cur = xmlnode_get_nextsibling(cur)) { if (0 == (j_strcmp(jp->to->user, xmlnode_get_data(cur)))) found = 1; } if (! found) { log_notice(p->host, "User tried to send message to invalid or " "unauthorized user!: %s",xmlnode2str(p->x)); return r_DONE; } } } We also added the following query to the xdb_sql.xml file: <querydef name="rosterck-get" dtd="2" type="get" namespace="jabber:iq:rostercheck"> <text>SELECT others.uid FROM memberships mem INNER JOIN memberships others ON others.unit_id = mem.unit_id AND others.unit_type = mem.unit_type INNER JOIN projects groups ON groups.id = mem.unit_id WHERE mem.unit_type = 'foo.base.Group.Project' AND mem.uid = SUBSTRING_INDEX( '$$user$$', '@', 1 ) AND others.uid != mem.uid</text> <user>$$user$$</user> <top-result><results xmlns='jabber:iq:rosterck'/></top-result> <bindcol tag="allowed" offset="0" /> </querydef> -Eli -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Moore, Michael Sent: Thursday, September 11, 2003 11:39 AM To: '[EMAIL PROTECTED]' Subject: [JDEV] Auto roster population/lock some groups Hi, I'm working on a jabber solution for the US Coast Guard. One feature they want is automatic roster population (no problem there). They also want to lock down the groups that were automatically populated so the user can't mess with them (not too hard) but here's the difficulty: they want to have a column in the rostergroups table to mark that the group was automatically generated. Using jabberd 1.4.2 on Linux with xdb_sql and a mysql database but we will be moving to Solaris and Oracle soon though, with the client in Java (and I've not used large-scale Java before... whee!). Then the client needs to block modification of those groups marked as auto-generated. I'm new to this whole project, I took over for someone a few weeks back and I'm still trying to figure it all out. The documentation I've read has confused me more than helped, and Google has not been my friend. Has anyone done anything like this (added stuff to the protocol)? Obviously the client needs to know how to handle it, but would it require changing the server source and rebuilding? Or just xdb_sql? Any pointers in the right direction would be appreciated. Thanks! *************************************************** Michael Moore ([EMAIL PROTECTED]) (304) 264-2652 Team CGCentral United States Coast Guard Operations Systems Center *************************************************** _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
