There are a number of problems with deploying container-based security.
It's an important feature, but it doesn't seem like a panacea.
What I would suggest is that we look at Nic's proposal from the
viewpoint of being able to also implement FORM-based security, using the
standard Java packages.
Craig's mentioned that it's not possible to set the role programatically
when container-based security is used, presumably because the container
does it. But I've been wondering if it is possible to set it
programatically when the container does NOT use it. For example, could
the controller set the role for every request -- instead of the
container.
Roles are helpful, but I think many real-life applications also need to
look at groups and permissions. If we had a security framework that
worked with or without the container's help, it would be worthwhile to
build fine-grained security into other parts of Struts.
-Ted.
PS - In related news, the slides from Craig's BOF on authentification
are available for download at More About Struts (Star Office format).
< http://husted.com/about/struts/resources.htm#new >
Oleg V Alexeev wrote:
>
> Hello Nic,
>
> Hm... Nic, I think that 'roles' attribute in ActionMapping is not
> solution - it helps to check path based security. So we have container
> security and struts security on one way - is it right? And more - one
> of the hard errors in J2EE projects is custom security mechanism
> (sorry, I forget URL to resource... :( )
>
> But more generally, your approach is interesting, I like it. If we
> must check access level for the function, not path, then it is good
> solution. I think every developer in struts community some day take a
> look to the security problem in his application - and your solution
> can be standart way to solve it.
