Yes, it is necesary; there isn't a LDAP based UserManager, and
DataSourceUserManager doesn't provide all the features I need
JP
-----Original Message-----
From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]]
Sent: Viernes, 19 de Enero de 2001 20:38
To: Orion-Interest
Subject: RE: Writing user managers
Is it really necessary to have your own user manager?
I model my users as entity EJBs. I use the vanilla
DataSourceUserManager mapped to the same table that the entities are
written to. All manipulation of user data is done through the entity
beans. The only trick is that you need to set:
<property name="staleness" value="0" />
in the <user-manager> block, otherwise entity changes won't show up.
This scheme pretty much minimizes the amount of server-specific code I
have to deal with.
Jeff
>-----Original Message-----
>From: Juan Lorandi (Chile) [mailto:[EMAIL PROTECTED]]
>Sent: Friday, January 19, 2001 10:32 AM
>To: Orion-Interest
>Subject: RE: Writing user managers
>
>
>The RoleManager depends entirely on the Useranager
>implementation that any
>given app is using.
>(If you decompile RoleManager, you'll find that it calls
>Application.UserManager's methods quite often)
>
>Roles in J2EE (RoleManager) map to groups in UserManager.
>
>I use three tables; one has user/password info, one has group
>definitions
>(roles), and another has user/group relations
>
>I will be much clearer once you start coding and testing...
>
>Oh, and whenever an app is first deployed, Orion (thru
>RoleManager then thru
>UserManager) will attempt to create a group
>for each declared role in every web.xml & ejb-jar.xml that
>finds within the
>application. That part of the init is automagical...
>
>I've had to make a back-end to the security(to create, edit and remove
>security data). You will have to create a user
>with access rights to this backend to start(in my case, a user:"sa"
>password:"" that was linked to a securityAdmin group).
>
>As a side note, this security is also used to access JNDI, and
>I haven't
>played much with it, but you'll have to check out
>the orion-XXXX.xml for namespace tags to enable read/write
>access to Orion's
>JNDI implementation. (Has a lot to do with the
>getAdministratorUser() in
>UserManager)
>
>HTH
>
>Juan Pablo
>
>
>
>-----Original Message-----
>From: Nick Newman [mailto:[EMAIL PROTECTED]]
>Sent: Viernes, 19 de Enero de 2001 15:24
>To: Juan Lorandi (Chile)
>Subject: RE: Writing user managers
>
>
>Sounds like it's not too hard. Great!
>
>One further question if I may. If Orion supplies its own
>implementation of
>the RoleManager which we cannot change, then does that mean we cannot
>specify the group-role mapping through anything but the xml
>files? Or is
>there some way that we could persuade Orion to use group-role
>mappings that
>are defined in a DB?
>
>Thanks,
>Nick
>
>At 12:51 PM 1/19/01 -0300, you wrote:
>>Group, User, and UserManager.
>>
>>Group and User are almost data transports; UserManager is
>where the work
>is,
>>but if you know a little of connectivity (say, you want
>persisted security
>>information in a DB, the jdbc is a must, or java.naming for LDAP, etc)
>>wouldn't take more than 20 man hours. RoleManager is a class, and it's
>never
>>implemented by the user. Supposedly, it's the neutral way to
>use security,
>>it works with roles, etc. If you have a functional UserManager
>>implementation, any code you write firing upon RoleManager
>will survive a
>>UserManager implementation change (or at least that's the idea)
>>
>>HTH
>
>
