On Thu, 29 Aug 2002, jfc wrote:
> ok,
>
> I use tomcat4+jboss2.4.x, struts1.1 and tiles on jdk1.3.1_01 and suse
> linux kernel2.4.13.
>
> My MVC view has to be able to determine which whether or not a request
> belongs to any particular role in order to perform its rendering.
>
> It seems to me there are two preconditions to the container being able
> to return authentication and authorization info (auth info) when the
> application invokes any of the three programmatic security methods i.e.
> getRemoteUser, isUserInRole and getUserPrincipal.
>
> 1. Tomcat needs to be operating in default mode regarding caching of
> auth info.
>
> or
>
> 2. all requests need to be routed to secured resources which will
> enforce the container's re-retrieval of auth info. making it available
> via the methods mentioned above.
>
> To my mind, choosing precondition 2 (because caching is turned off)
> means that I would have to define multiple struts mappings for each and
> every piece of functionality based on role. e.g. if I have a
> '/do/greeting', I now have to have '/do/roleA/greeting', a
> '/do/roleB/greeting' etc. with /do/roleA/* declared as secure under
> roleA. I am concerned this will result in a bloated struts-config.xml
> and am not sure this is the way to go.
>
> So, to put it another way, I dont want to have to rely on this
> information having to be encoded in the URL because this translates to
> having the same action mapping duplicated for each role. Maybe I'm
> making it more difficult than it is and if so I ask you to bear with me
> a bit ;-)
>
> I accept what you say when you say I should be talking to the jboss guys
> but I would like confirmation that my solution lies in one of the two
> points mentioned above.
>
Unfortunately, I can give you no such assurance ... I don't have any clue
at all about what JBoss did in their integration of Tomcat, so I don't
know what other behavior might have changed. All I can
tell you is that Tomcat, in default mode, remembers authentication and
authorization information if you're using sessions.
A side effect of this is that the information is still valid when you
access an unsecured resource after logging on. This behavior is not
required by the servlet spec, and (from discussions in the Servlet 2.4
expert group) I am pretty sure that it's done differently by different
containers.
So, looking for a portable solution, something like what you're suggesting
(multiple mappings) sounds like it might work.
> Thanks for your time on this Craig. If I can get around the caching
> using point 2. then could you suggest a way to implement the action
> paths in struts or anotherway of doing it?
>
In the Struts-specific realm, the "roles" attribute on an action takes a
comma-delimited list of roles, and by default Struts implements an "OR"
test -- if the user has *any* of the listed roles, access is allowed. I
don't know if you can model your role names so that this helps, but it
might be feasible to just protect all of the action paths with a security
constraint on a role that every user is granted, and then use this list in
struts-config for finer-grained control over specific actions without
having to map them more than once.
If you needed an AND test instead, it would be easy to subclass the Struts
request processor and override the processRoles() method to achieve this.
> jfc
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
