Adding memebers to groupdatabase.xml problem

[anitasingh]

Hi,

We have installed jspwiki 2.4.102 on Websphere5.1 and Tomcat. It works great except one problem.

We add users and assign them to different groups through another existing system. The existing system
updates the userdatabase.xml to add the user to wiki and also adds the user to chosen group in groupdatabase.xml.

When we add a new user to userdatabase.xml the user has immidiate login to jspwiki but when we assign the user to a group,  his group privileges doesn't work until we restart japwiki.
If we assign the user to a  group through jspwiki admin, we do not need to restart wiki for the user to get his privileges.

Is this by design or I am missing something in configuration.
If its by design, what I can do to not have to restart jspwiki everytime we add a member to an existing group through another backend system.

Appreciate your help.
TIA

[Janne Jalkanen]

Hi!

JSPWiki assumes it owns the backend.  So changing the backend outside  
of JSPWiki system is simply not supported.  The fact that it happens  
to work in some cases is completely accidental.

The only way to change this behaviour is to change the  
XMLGroupDatabase, or write your own GroupDatabase implementation.

/Janne

On 15 Aug 2008, at 00:26, anitasingh wrote:

>
> Hi,
>
> We have installed jspwiki 2.4.102 on Websphere5.1 and Tomcat. It  
> works great
> except one problem.
>
> We add users and assign them to different groups through another  
> existing
> system. The existing system
> updates the userdatabase.xml to add the user to wiki and also adds  
> the user
> to chosen group in groupdatabase.xml.
>
> When we add a new user to userdatabase.xml the user has immidiate  
> login to
> jspwiki but when we assign the user to a group,  his group privileges
> doesn't work until we restart japwiki.
> If we assign the user to a  group through jspwiki admin, we do not  
> need to
> restart wiki for the user to get his privileges.
>
> Is this by design or I am missing something in configuration.
> If its by design, what I can do to not have to restart jspwiki  
> everytime we
> add a member to an existing group through another backend system.
>
> Appreciate your help.
> TIA
>
>
> --
> View this message in context: http://www.nabble.com/Adding-memebers- 
> to-groupdatabase.xml-problem-tp18990033p18990033.html
> Sent from the JspWiki - User mailing list archive at Nabble.com.

[Jim Willeke]

We are using LDAP and have an attribute on the Users within LDAP to
implement the groups.

In out tomcat server.xml file:
                        <Realm className="org.apache.catalina.realm.JNDIRealm" debug="10"
                                connectionURL="ldap://192.168.x.x:389"
                                alternateURL="ldap://192.168.xx.xx:389"
                                userBase="ou=people,dc=willeke,dc=com"
                                userSearch="(cn={0})"
                                userSubtree="true"
                                userRoleName="dictcrole"
                                connectionName="cn=admin,ou=administration,dc=willeke,dc=com"
                                connectionPassword="secret"

Then a typical user in LDAP:
dictcRole=manager
dictcRole=Authenticated
dictcRole=linux

Which represent the groups used within the Wiki.
(Ok we really use these same attributes for other apps too)

When a value is changed in LDAP, they are effective on the next login.
-jim


On Thu, Aug 14, 2008 at 5:51 PM, Janne Jalkanen
<Janne.Jalkanen@...> wrote:

>
> Hi!
>
> JSPWiki assumes it owns the backend.  So changing the backend outside of
> JSPWiki system is simply not supported.  The fact that it happens to work in
> some cases is completely accidental.
>
> The only way to change this behaviour is to change the XMLGroupDatabase, or
> write your own GroupDatabase implementation.
>
> /Janne
>
> On 15 Aug 2008, at 00:26, anitasingh wrote:
>
>>
>> Hi,
>>
>> We have installed jspwiki 2.4.102 on Websphere5.1 and Tomcat. It works
>> great
>> except one problem.
>>
>> We add users and assign them to different groups through another existing
>> system. The existing system
>> updates the userdatabase.xml to add the user to wiki and also adds the
>> user
>> to chosen group in groupdatabase.xml.
>>
>> When we add a new user to userdatabase.xml the user has immidiate login to
>> jspwiki but when we assign the user to a group,  his group privileges
>> doesn't work until we restart japwiki.
>> If we assign the user to a  group through jspwiki admin, we do not need to
>> restart wiki for the user to get his privileges.
>>
>> Is this by design or I am missing something in configuration.
>> If its by design, what I can do to not have to restart jspwiki everytime
>> we
>> add a member to an existing group through another backend system.
>>
>> Appreciate your help.
>> TIA
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Adding-memebers-to-groupdatabase.xml-problem-tp18990033p18990033.html
>> Sent from the JspWiki - User mailing list archive at Nabble.com.
>
>

--
-jim
Jim Willeke

[Andrew Jaquith-3]

Hi Jim --

The issue you've described is really about container ROLES, not  
JSPWiki groups. The two are fundamentally different in terms of how  
JSPWiki deals with them. Let me explain.

First, ROLES are assigned by the system -- either JSPWiki or  
externally by the web application server (aka web container). Roles  
can be either "built-in" or container-managed. By "built-in" roles, we  
mean roles ALL, AUTHENTICATED, ANONYMOUS, and ASSERTED. These are  
related to the user's current authentication state, and are assigned  
by JSPWiki as part of the authentication system.

Container-managed roles are those that are maintained outside of  
JSPWiki by the web container. The JNDIRealm you described, for  
example, is a container-managed realm that supplies roles that JSPWiki  
can use. For JSPWiki to use them, they must be declared in the JSPWiki  
webapp's web.xml file (typically using role-ref elements). At startup,  
JSPWiki parses web.xml and caches the set of roles that are declared  
there. When a user logs in, we check to see whether the user is a  
member of any of those roles. If so, the user is regarded as  
"belonging" to that role. It is important to remember, again, that  
what we are talking about here is ROLE membership, not GROUP membership.

Second, GROUPS are discretionary sets of users that have decided to  
associate themselves into a group. Functionally, they are just like  
roles, but with a key difference: groups are managed by JSPWiki and  
not by the container. Technically, groups are stored using a  
GroupDatabase implementation; by default, this is the XML-based  
XMLGroupDatabase. Groups were deliberately meant to be managed outside  
of the web container, so that users can create discretionary "roles"  
without getting system admins involved. This is an intentional  
feature, and a very powerful one.

 From the standpoint of how roles and groups are implemented, there  
are some key differences to be aware of. Because groups are managed by  
JSPWiki, we have complete control of querying the database, adding and  
deleting groups, and testing for membership. That means that users who  
are added to groups receive these privileges immediately.

Roles (container-managed ones, anyway) are treated differently by  
necessity. The set of roles that JSPWiki "knows" about is determined  
only once -- when the webapp starts. Specifically, this happens when  
WebContainerAuthorizer's initialize() method parses web.xml.

Next, users are tested for membership in that set of "known" container  
roles (by calling HttpServletResponse.isInRole()) also only once --  
when they log in. We do this for performance reasons: it would be a  
huge drain on performance to query the set of known container roles  
every time we needed to do an authorization check (which could be done  
several dozen times PER page).

 From the policy and access control list (ACL) perspective, you can  
use both roles and groups interchangeably, although the policy file  
syntax differs slightly. To grant privileges via the jspwiki.policy  
file to a role (either container-managed, or a built-in one), you use  
the Principal com.ecyrd.jspwiki.auth.authorize.Role. For groups, you  
use Principal com.ecyrd.jspwiki.auth.GroupPrincipal.

If you grant privileges in ACLs, you don't need to specify whether  
it's a role or group; you can just specify names like Foo, Bar, All,  
or Authenticated. JSPWiki prioritizes "built-in" roles All/
Authenticated/Asserted/Anonymous first, then container-managed roles,  
then groups, then regular user names. This is the order in which  
naming conflicts are resolved. So, if your container emits a role  
called "Anonymous," JSPWiki will ignore it because it conflicts with a  
built-in role by that name. We do this to prevent spoofing.

Boiling this all down, here's what it means:
1. Container-managed roles (e.g., supplied by JNDIRealm) are NOT groups
2. If you add new roles to your container, they will not be recognized  
until you a) a modify web.xml to declare the role **AND** b) restart  
JSPWiki
3. If you change an existing role managed by your container, users  
won't see their privileges change until the next time they log in
4. Group changes have neither of these restrictions, and take effect  
immediately

It sounds like the problem you have is related to points 2 and 3. I'd  
suggest that you take a careful look at how you are provisioning roles  
with your web container. Do you need to keep all of them in your web  
container (as roles), rather than in JSPWiki (as groups)? If they  
don't really require an admin to create them, consider changing some  
of the roles into groups instead (and let the users manage them).

If you want to let users create the groups themselves -- AND need to  
share them with other apps -- you might instead want to implement your  
own GroupDatabase to interface with JNDI. Bear in mind, however, that  
GroupDatabases are expected to have read-write access to the back end  
(LDAP in your example). If you need to restrict who gets to create  
groups, of course, you can do this by modifying your security policy.  
So even though your (hypothetical) JNDIGroupDatabase would have full  
access to the branch of LDAP that stores your multi-app groups, you  
could still make sure that just the "Admin" group (or "Admin"  
container role) would be the only ones adding or editing groups.

Regards,

Andrew

On Aug 15, 2008, at 7:42 AM, Jim Willeke wrote:

> We are using LDAP and have an attribute on the Users within LDAP to
> implement the groups.
>
> In out tomcat server.xml file:
> <Realm className="org.apache.catalina.realm.JNDIRealm" debug="10"
> connectionURL="ldap://192.168.x.x:389"
> alternateURL="ldap://192.168.xx.xx:389"
> userBase="ou=people,dc=willeke,dc=com"
> userSearch="(cn={0})"
> userSubtree="true"
> userRoleName="dictcrole"
> connectionName="cn=admin,ou=administration,dc=willeke,dc=com"
> connectionPassword="secret"
>
> Then a typical user in LDAP:
> dictcRole=manager
> dictcRole=Authenticated
> dictcRole=linux
>
> Which represent the groups used within the Wiki.
> (Ok we really use these same attributes for other apps too)
>
> When a value is changed in LDAP, they are effective on the next login.
> -jim
>
>
> On Thu, Aug 14, 2008 at 5:51 PM, Janne Jalkanen
> <Janne.Jalkanen@...> wrote:
>>
>> Hi!
>>
>> JSPWiki assumes it owns the backend.  So changing the backend  
>> outside of
>> JSPWiki system is simply not supported.  The fact that it happens  
>> to work in
>> some cases is completely accidental.
>>
>> The only way to change this behaviour is to change the  
>> XMLGroupDatabase, or
>> write your own GroupDatabase implementation.
>>
>> /Janne
>>
>> On 15 Aug 2008, at 00:26, anitasingh wrote:
>>
>>>
>>> Hi,
>>>
>>> We have installed jspwiki 2.4.102 on Websphere5.1 and Tomcat. It  
>>> works
>>> great
>>> except one problem.
>>>
>>> We add users and assign them to different groups through another  
>>> existing
>>> system. The existing system
>>> updates the userdatabase.xml to add the user to wiki and also adds  
>>> the
>>> user
>>> to chosen group in groupdatabase.xml.
>>>
>>> When we add a new user to userdatabase.xml the user has immidiate  
>>> login to
>>> jspwiki but when we assign the user to a group,  his group  
>>> privileges
>>> doesn't work until we restart japwiki.
>>> If we assign the user to a  group through jspwiki admin, we do not  
>>> need to
>>> restart wiki for the user to get his privileges.
>>>
>>> Is this by design or I am missing something in configuration.
>>> If its by design, what I can do to not have to restart jspwiki  
>>> everytime
>>> we
>>> add a member to an existing group through another backend system.
>>>
>>> Appreciate your help.
>>> TIA
>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Adding-memebers-to-groupdatabase.xml-problem-tp18990033p18990033.html
>>> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> -jim
> Jim Willeke

[Harry Metske]

Andrew,

thanks for this excellent explanation, it is very clear and usable.

regards,
Harry

2008/8/18 Andrew Jaquith <andrew.jaquith@...>

> Hi Jim --
>
> The issue you've described is really about container ROLES, not JSPWiki
> groups. The two are fundamentally different in terms of how JSPWiki deals
> with them. Let me explain.
>
> First, ROLES are assigned by the system -- either JSPWiki or externally by
> the web application server (aka web container). Roles can be either
> "built-in" or container-managed. By "built-in" roles, we mean roles ALL,
> AUTHENTICATED, ANONYMOUS, and ASSERTED. These are related to the user's
> current authentication state, and are assigned by JSPWiki as part of the
> authentication system.
>
> Container-managed roles are those that are maintained outside of JSPWiki by
> the web container. The JNDIRealm you described, for example, is a
> container-managed realm that supplies roles that JSPWiki can use. For
> JSPWiki to use them, they must be declared in the JSPWiki webapp's web.xml
> file (typically using role-ref elements). At startup, JSPWiki parses web.xml
> and caches the set of roles that are declared there. When a user logs in, we
> check to see whether the user is a member of any of those roles. If so, the
> user is regarded as "belonging" to that role. It is important to remember,
> again, that what we are talking about here is ROLE membership, not GROUP
> membership.
>
> Second, GROUPS are discretionary sets of users that have decided to
> associate themselves into a group. Functionally, they are just like roles,
> but with a key difference: groups are managed by JSPWiki and not by the
> container. Technically, groups are stored using a GroupDatabase
> implementation; by default, this is the XML-based XMLGroupDatabase. Groups
> were deliberately meant to be managed outside of the web container, so that
> users can create discretionary "roles" without getting system admins
> involved. This is an intentional feature, and a very powerful one.
>
> From the standpoint of how roles and groups are implemented, there are some
> key differences to be aware of. Because groups are managed by JSPWiki, we
> have complete control of querying the database, adding and deleting groups,
> and testing for membership. That means that users who are added to groups
> receive these privileges immediately.
>
> Roles (container-managed ones, anyway) are treated differently by
> necessity. The set of roles that JSPWiki "knows" about is determined only
> once -- when the webapp starts. Specifically, this happens when
> WebContainerAuthorizer's initialize() method parses web.xml.
>
> Next, users are tested for membership in that set of "known" container
> roles (by calling HttpServletResponse.isInRole()) also only once -- when
> they log in. We do this for performance reasons: it would be a huge drain on
> performance to query the set of known container roles every time we needed
> to do an authorization check (which could be done several dozen times PER
> page).
>
> From the policy and access control list (ACL) perspective, you can use both
> roles and groups interchangeably, although the policy file syntax differs
> slightly. To grant privileges via the jspwiki.policy file to a role (either
> container-managed, or a built-in one), you use the Principal
> com.ecyrd.jspwiki.auth.authorize.Role. For groups, you use Principal
> com.ecyrd.jspwiki.auth.GroupPrincipal.
>
> If you grant privileges in ACLs, you don't need to specify whether it's a
> role or group; you can just specify names like Foo, Bar, All, or
> Authenticated. JSPWiki prioritizes "built-in" roles
> All/Authenticated/Asserted/Anonymous first, then container-managed roles,
> then groups, then regular user names. This is the order in which naming
> conflicts are resolved. So, if your container emits a role called
> "Anonymous," JSPWiki will ignore it because it conflicts with a built-in
> role by that name. We do this to prevent spoofing.
>
> Boiling this all down, here's what it means:
> 1. Container-managed roles (e.g., supplied by JNDIRealm) are NOT groups
> 2. If you add new roles to your container, they will not be recognized
> until you a) a modify web.xml to declare the role **AND** b) restart JSPWiki
> 3. If you change an existing role managed by your container, users won't
> see their privileges change until the next time they log in
> 4. Group changes have neither of these restrictions, and take effect
> immediately
>
> It sounds like the problem you have is related to points 2 and 3. I'd
> suggest that you take a careful look at how you are provisioning roles with
> your web container. Do you need to keep all of them in your web container
> (as roles), rather than in JSPWiki (as groups)? If they don't really require
> an admin to create them, consider changing some of the roles into groups
> instead (and let the users manage them).
>
> If you want to let users create the groups themselves -- AND need to share
> them with other apps -- you might instead want to implement your own
> GroupDatabase to interface with JNDI. Bear in mind, however, that
> GroupDatabases are expected to have read-write access to the back end (LDAP
> in your example). If you need to restrict who gets to create groups, of
> course, you can do this by modifying your security policy. So even though
> your (hypothetical) JNDIGroupDatabase would have full access to the branch
> of LDAP that stores your multi-app groups, you could still make sure that
> just the "Admin" group (or "Admin" container role) would be the only ones
> adding or editing groups.
>
> Regards,
>
> Andrew
>
> On Aug 15, 2008, at 7:42 AM, Jim Willeke wrote:
>
>  We are using LDAP and have an attribute on the Users within LDAP to
>> implement the groups.
>>
>> In out tomcat server.xml file:
>>                        <Realm
>> className="org.apache.catalina.realm.JNDIRealm" debug="10"
>>                                connectionURL="ldap://192.168.x.x:389"
>>                                alternateURL="ldap://192.168.xx.xx:389"
>>                                userBase="ou=people,dc=willeke,dc=com"
>>                                userSearch="(cn={0})"
>>                                userSubtree="true"
>>                                userRoleName="dictcrole"
>>
>>  connectionName="cn=admin,ou=administration,dc=willeke,dc=com"
>>                                connectionPassword="secret"
>>
>> Then a typical user in LDAP:
>> dictcRole=manager
>> dictcRole=Authenticated
>> dictcRole=linux
>>
>> Which represent the groups used within the Wiki.
>> (Ok we really use these same attributes for other apps too)
>>
>> When a value is changed in LDAP, they are effective on the next login.
>> -jim
>>
>>
>> On Thu, Aug 14, 2008 at 5:51 PM, Janne Jalkanen
>> <Janne.Jalkanen@...> wrote:
>>
>>>
>>> Hi!
>>>
>>> JSPWiki assumes it owns the backend.  So changing the backend outside of
>>> JSPWiki system is simply not supported.  The fact that it happens to work
>>> in
>>> some cases is completely accidental.
>>>
>>> The only way to change this behaviour is to change the XMLGroupDatabase,
>>> or
>>> write your own GroupDatabase implementation.
>>>
>>> /Janne
>>>
>>> On 15 Aug 2008, at 00:26, anitasingh wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> We have installed jspwiki 2.4.102 on Websphere5.1 and Tomcat. It works
>>>> great
>>>> except one problem.
>>>>
>>>> We add users and assign them to different groups through another
>>>> existing
>>>> system. The existing system
>>>> updates the userdatabase.xml to add the user to wiki and also adds the
>>>> user
>>>> to chosen group in groupdatabase.xml.
>>>>
>>>> When we add a new user to userdatabase.xml the user has immidiate login
>>>> to
>>>> jspwiki but when we assign the user to a group,  his group privileges
>>>> doesn't work until we restart japwiki.
>>>> If we assign the user to a  group through jspwiki admin, we do not need
>>>> to
>>>> restart wiki for the user to get his privileges.
>>>>
>>>> Is this by design or I am missing something in configuration.
>>>> If its by design, what I can do to not have to restart jspwiki everytime
>>>> we
>>>> add a member to an existing group through another backend system.
>>>>
>>>> Appreciate your help.
>>>> TIA
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>>
>>>> http://www.nabble.com/Adding-memebers-to-groupdatabase.xml-problem-tp18990033p18990033.html
>>>> Sent from the JspWiki - User mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> -jim
>> Jim Willeke
>>
>
>

--
met vriendelijke groet,
Harry Metske
Telnr. [phone]
Mobile [phone]

[Terry Steichen]

Andrew,

Good explanation.  Hope you post in to JSPWiki documentation

Terry

On Mon, 2008-08-18 at 00:29 -0400, Andrew Jaquith wrote:

> Hi Jim --
>
> The issue you've described is really about container ROLES, not  
> JSPWiki groups. The two are fundamentally different in terms of how  
> JSPWiki deals with them. Let me explain.
>
> First, ROLES are assigned by the system -- either JSPWiki or  
> externally by the web application server (aka web container). Roles  
> can be either "built-in" or container-managed. By "built-in" roles, we  
> mean roles ALL, AUTHENTICATED, ANONYMOUS, and ASSERTED. These are  
> related to the user's current authentication state, and are assigned  
> by JSPWiki as part of the authentication system.
>
> Container-managed roles are those that are maintained outside of  
> JSPWiki by the web container. The JNDIRealm you described, for  
> example, is a container-managed realm that supplies roles that JSPWiki  
> can use. For JSPWiki to use them, they must be declared in the JSPWiki  
> webapp's web.xml file (typically using role-ref elements). At startup,  
> JSPWiki parses web.xml and caches the set of roles that are declared  
> there. When a user logs in, we check to see whether the user is a  
> member of any of those roles. If so, the user is regarded as  
> "belonging" to that role. It is important to remember, again, that  
> what we are talking about here is ROLE membership, not GROUP membership.
>
> Second, GROUPS are discretionary sets of users that have decided to  
> associate themselves into a group. Functionally, they are just like  
> roles, but with a key difference: groups are managed by JSPWiki and  
> not by the container. Technically, groups are stored using a  
> GroupDatabase implementation; by default, this is the XML-based  
> XMLGroupDatabase. Groups were deliberately meant to be managed outside  
> of the web container, so that users can create discretionary "roles"  
> without getting system admins involved. This is an intentional  
> feature, and a very powerful one.
>
>  From the standpoint of how roles and groups are implemented, there  
> are some key differences to be aware of. Because groups are managed by  
> JSPWiki, we have complete control of querying the database, adding and  
> deleting groups, and testing for membership. That means that users who  
> are added to groups receive these privileges immediately.
>
> Roles (container-managed ones, anyway) are treated differently by  
> necessity. The set of roles that JSPWiki "knows" about is determined  
> only once -- when the webapp starts. Specifically, this happens when  
> WebContainerAuthorizer's initialize() method parses web.xml.
>
> Next, users are tested for membership in that set of "known" container  
> roles (by calling HttpServletResponse.isInRole()) also only once --  
> when they log in. We do this for performance reasons: it would be a  
> huge drain on performance to query the set of known container roles  
> every time we needed to do an authorization check (which could be done  
> several dozen times PER page).
>
>  From the policy and access control list (ACL) perspective, you can  
> use both roles and groups interchangeably, although the policy file  
> syntax differs slightly. To grant privileges via the jspwiki.policy  
> file to a role (either container-managed, or a built-in one), you use  
> the Principal com.ecyrd.jspwiki.auth.authorize.Role. For groups, you  
> use Principal com.ecyrd.jspwiki.auth.GroupPrincipal.
>
> If you grant privileges in ACLs, you don't need to specify whether  
> it's a role or group; you can just specify names like Foo, Bar, All,  
> or Authenticated. JSPWiki prioritizes "built-in" roles All/
> Authenticated/Asserted/Anonymous first, then container-managed roles,  
> then groups, then regular user names. This is the order in which  
> naming conflicts are resolved. So, if your container emits a role  
> called "Anonymous," JSPWiki will ignore it because it conflicts with a  
> built-in role by that name. We do this to prevent spoofing.
>
> Boiling this all down, here's what it means:
> 1. Container-managed roles (e.g., supplied by JNDIRealm) are NOT groups
> 2. If you add new roles to your container, they will not be recognized  
> until you a) a modify web.xml to declare the role **AND** b) restart  
> JSPWiki
> 3. If you change an existing role managed by your container, users  
> won't see their privileges change until the next time they log in
> 4. Group changes have neither of these restrictions, and take effect  
> immediately
>
> It sounds like the problem you have is related to points 2 and 3. I'd  
> suggest that you take a careful look at how you are provisioning roles  
> with your web container. Do you need to keep all of them in your web  
> container (as roles), rather than in JSPWiki (as groups)? If they  
> don't really require an admin to create them, consider changing some  
> of the roles into groups instead (and let the users manage them).
>
> If you want to let users create the groups themselves -- AND need to  
> share them with other apps -- you might instead want to implement your  
> own GroupDatabase to interface with JNDI. Bear in mind, however, that  
> GroupDatabases are expected to have read-write access to the back end  
> (LDAP in your example). If you need to restrict who gets to create  
> groups, of course, you can do this by modifying your security policy.  
> So even though your (hypothetical) JNDIGroupDatabase would have full  
> access to the branch of LDAP that stores your multi-app groups, you  
> could still make sure that just the "Admin" group (or "Admin"  
> container role) would be the only ones adding or editing groups.
>
> Regards,
>
> Andrew
>
> On Aug 15, 2008, at 7:42 AM, Jim Willeke wrote:
>
> > We are using LDAP and have an attribute on the Users within LDAP to
> > implement the groups.
> >
> > In out tomcat server.xml file:
> > <Realm className="org.apache.catalina.realm.JNDIRealm" debug="10"
> > connectionURL="ldap://192.168.x.x:389"
> > alternateURL="ldap://192.168.xx.xx:389"
> > userBase="ou=people,dc=willeke,dc=com"
> > userSearch="(cn={0})"
> > userSubtree="true"
> > userRoleName="dictcrole"
> > connectionName="cn=admin,ou=administration,dc=willeke,dc=com"
> > connectionPassword="secret"
> >
> > Then a typical user in LDAP:
> > dictcRole=manager
> > dictcRole=Authenticated
> > dictcRole=linux
> >
> > Which represent the groups used within the Wiki.
> > (Ok we really use these same attributes for other apps too)
> >
> > When a value is changed in LDAP, they are effective on the next login.
> > -jim
> >
> >
> > On Thu, Aug 14, 2008 at 5:51 PM, Janne Jalkanen
> > <Janne.Jalkanen@...> wrote:
> >>
> >> Hi!
> >>
> >> JSPWiki assumes it owns the backend.  So changing the backend  
> >> outside of
> >> JSPWiki system is simply not supported.  The fact that it happens  
> >> to work in
> >> some cases is completely accidental.
> >>
> >> The only way to change this behaviour is to change the  
> >> XMLGroupDatabase, or
> >> write your own GroupDatabase implementation.
> >>
> >> /Janne
> >>
> >> On 15 Aug 2008, at 00:26, anitasingh wrote:
> >>
> >>>
> >>> Hi,
> >>>
> >>> We have installed jspwiki 2.4.102 on Websphere5.1 and Tomcat. It  
> >>> works
> >>> great
> >>> except one problem.
> >>>
> >>> We add users and assign them to different groups through another  
> >>> existing
> >>> system. The existing system
> >>> updates the userdatabase.xml to add the user to wiki and also adds  
> >>> the
> >>> user
> >>> to chosen group in groupdatabase.xml.
> >>>
> >>> When we add a new user to userdatabase.xml the user has immidiate  
> >>> login to
> >>> jspwiki but when we assign the user to a group,  his group  
> >>> privileges
> >>> doesn't work until we restart japwiki.
> >>> If we assign the user to a  group through jspwiki admin, we do not  
> >>> need to
> >>> restart wiki for the user to get his privileges.
> >>>
> >>> Is this by design or I am missing something in configuration.
> >>> If its by design, what I can do to not have to restart jspwiki  
> >>> everytime
> >>> we
> >>> add a member to an existing group through another backend system.
> >>>
> >>> Appreciate your help.
> >>> TIA
> >>>
> >>>
> >>> --
> >>> View this message in context:
> >>> http://www.nabble.com/Adding-memebers-to-groupdatabase.xml-problem-tp18990033p18990033.html
> >>> Sent from the JspWiki - User mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> >
> > --
> > -jim
> > Jim Willeke