[JDEV] Auto roster population/lock some groups

[Moore, Michael]

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 (mmoore at osc.uscg.mil) (304) 264-2652
Team CGCentral
United States Coast Guard Operations Systems Center
***************************************************

-----Original Message-----
From: Eli Burke [mailto:eburke at lore.net]
Sent: Thursday, September 11, 2003 2:01 PM
To: jdev at jabber.org
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: jdev-admin at jabber.org [mailto:jdev-admin at jabber.org] On Behalf Of
Moore, Michael
Sent: Thursday, September 11, 2003 11:39 AM
To: 'jdev at jabber.org'
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 (mmoore at osc.uscg.mil) (304) 264-2652
Team CGCentral
United States Coast Guard Operations Systems Center
***************************************************




_______________________________________________
jdev mailing list
jdev at jabber.org
http://mailman.jabber.org/listinfo/jdev