In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
says...
> As long as you have users that have passwords, and that might be in zero or
> more roles, it should be relatively easy to write a realm implementation
> that would access your custom user information repository. That would allow
> you to make use of the J2EE container managed security system, which solves
> your problem about keeping POSTed request parameters across a login event.
> If there is any way this would work, it seems likely to be the best (least
> work, most rubust, has some positive side effects) way to go.

It does sound like the "right" way to go... however, I have two 
reservations:

1. As I understand it, have to have hard coded role names in the web.xml 
file.  For example:
        <auth-constraint>
                <role-name>XXXX</role-name>
        </auth-constraint>
This means that anytime I create new roles, I have to update two places.  
Given that I probably won't be doing that too often, that may not be a 
problem.

2. I am only just learning Struts and the notion of writing a Realm 
implementation would be yet another thing I have to come to grips with 
before being able to build application functionality.  I'm wary of 
overengineering at this tender stage...

Having said all that, in trying to describe my problem I think I can 
clarify it by saying: 

- If a user requests a "private" page, the framework should authenticate 
them and then redirect them to the private page.
- If a user requests a page for which they are not authorized, they will 
be redirected to a static "not authorized" page. 

Perhaps I can create one J2EE role called LOGGEDON and use container 
managed security to handle the redirection.  This way, I can use J2EE to 
deal with *authentication*, but I can still manage *authorisation* 
within my Action framework.  Maybe...

-- 
Craig Edwards
Sydney, Australia


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

Reply via email to