On Sun, 23 Jan 2005 18:39:50 +0000, Tim Christopher
<[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I am designing a web application using Struts, which will run using
> Tomcat.  The system will have upwards of 1000 users, with each user
> having any number of around 10 possible roles.
> 
> I'm currently thinking of using JDBCRealm within the Tomcat xml file
> to set the roles for each of the users, then extending the
> RequestProcessor to ensure only authorised users can enter the secure
> area.  I then have a number of menu options that should only be made
> visible to users with certain roles; I intend to use logic:present
> role=".." or req:isUserInRole role="..." to do this - from what I can
> see they are functionally identical(?).
> 

The implementation of logic:present role= uses request.isUserInRole()
under the covers :-).

> I guess what I'd like to know is:
>  * Will this approach actually work?

Yep.

>  * Is there a better way?

This sounds best for your use case.

>  * Will any changes to user roles made within the database
> automatically update the roles that tomcat uses from the JDBCRealm, or
> will it require a server restart?

Tomcat's JDBCRealm caches the relevant roles for a user when he or she
logs on, so they won't change for the length of that session ... but
changes will get reflected next time the same person logs on.

>  * Also if I use a check within the jsp like logic:present role=".."
> to decide if a component should be dispalyed, I have read it is also
> advisable to require to presence of a role to use the Action.  This
> method will require two updates to allow an additional an additional
> role to access a resource (update in the jsp, and in the xml file) -
> is there a way around this?

You can prohibit direct access to JSP pages (requiring that they go
through an Action first) and only need to configure the XML file to
limit access to a complete page.  But you'll still need the inner
logic if you want to do things differently, based on role, within a
page.

> 
> Thank you in advance,
> 
> Tim Christopher
> 

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to