RE: User/Session/Auth Module

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On 
> Behalf Of Derick Fernando
> Sent: Thursday, October 17, 2002 8:03 PM
> To: 'jpublish-developer'
> Subject: [JPublish-developer] User/Session/Auth Module
> 
> 
> I looked in jpublish/modules/user/src/org/jpublish/module/user.
> Saw the Quartz module, nice to see a scheduler already there :).

Too bad I could never get it to work completely. :-(  I worked with the
Quartz developers for a while trying to get it to work but to no avail.
Perhaps with the current release of Quartz it will work.

> As far as the User/Auth/Session Module here are my thoughts:
> 
> Are you planning on making the Database end more abstract? 
> Like user defined columns, tables where the user objects are stored?

Yes.  I only hardcoded them initially because it was easy.  It would be
a small step to specify the queries in the jpublish.xml configuration
file at the point where the module is loaded.
 
> Also, on the Module I've been working on, I have a Listener 
> class which implements HttpSessionListener. The point of 
> which is basically so the App can be aware of how many users 
> are on, and how many guests are on. I find that basic 
> functionality missing in other frameworks, but common, in 
> PHP, ASP. So would that be a feature to keep?

Yes, that sounds like a nice feature.

> Declarative security is already present in the Servlet API, 
> JPublish supports this well. So I am asuming the Auth Module 
> is for a Programmatic Security model, in other words all 
> permissions are checked in application specific code.

Not necessarily.  The Auth module can be used as a container-independent
replacement for the declarative security of the Servlet API.  Actually,
working with it programatically will require that the UserManager is
also exposed in the current context, so I added another action
(ExposeUserManagerAction.java) for that.

> Will the Module rely on a <path-action path="/secure/*" 
> name="CheckUserRights"/> element since checking every request 
> would be a waste of resources.

Yes.  Modules will always be just a collection of actions, and thus the
actions will need to be exposed.   The actual action is the
FindUserAction class which is exposed to JPublish under the name
"user.findUser".

> UserManager: Has a default Manager like DBUserManager, Can be 
> replaced in config to allow another Manager like 
> LDAPUserManager. Perhaps this would also allow allow users to 
> use their own digest algorithm for encrypting passwords [ 
> Your implementation looks like its headed in this direction?
> :) ].
>

You are correct.  The UserManager implementation class should be defined
in the jpublish.xml file and is passed to the FindUserAction.  I have
checked in some additional code to move more towards this, and the User
module should build, but it doesn't yet function.

> I think some of these methods would make life easier:
> 
> Auth
> ----------------------------
> getUser(Session)
> getUserPrincipal(Username)
> getUserRoles(Username)
> getUserPermissions(Username)
> hasRole(Role)
> hasPermission(Permission)
> 
> Session
> ----------------------------
> getGuestCount()
> getUserCount()
> getCurrentUsers()
> getCurrentGuests()
> 
> ------------------------------------------------------
> Table Structure:
> 
> Permissions: Permission ID, Permission Name (A List of 
> permissions such as "modify artcile, change username, etc)
> Roles: Role name, Role ID (A list of roles)
> Group: Group name, Group ID (A list of groups)
> GroupRoles: Group ID, Role ID (A user in this group has this role)
> GroupPermission: Group ID, Permission ID (A user in this 
> group has this
> permission)
> User: UserID, LoginName, PasswordValue, FirstName, LastName, 
> Email, Modified, Created, LastLogin
> UserRoles: UserId, RoleID (Roles user is in)
> UserPermissions: UserID, PermissionID (Permissions user has)
> UserGroups: UserID, GroupID (Groups user is in)
> 
> Does this sound like too much? What type of User module do we 
> want? I will write more later when we get into specifics :).

That is a lot of stuff, but I think it is reasonable to expect it.  If
you would like to put some effort into it I will add contributions back
into the CVS and give you credit.  I don't think I can spend a lot of
time on this in the near future, but if I get some time to hack away at
it I will use your ideas as the base because I think you are right on
target with the proposed methods and table structure.

Sincerely,
Anthony Eden



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf