anonymous wrote : <s:secure> is gone, it's been replaced with EL expressions
s:hasRole and s:hasPermission.
Does this mean that the "view" will also have servlet container security
enabled on it? In my own Seam application I've places only the controller Seam
BBs within a security domain. Thus these components can use the @RolesAllowed
stuff. I'm using a servlet filter to push the session credentials to the
client-login JAAS context. My view has no servlet container security enabled on
it, but it can access the current used via #{currentUser} if needed for view
purposes only, since that's the only task of the view (SoC). For this I used a
simple Tomcat valve configured via context.xml.
IMHO the view should not have security enabled on it, since it can only expose
data or perform operations via the controller components. Thus placing the
controller components inside a security domain does the trick. Servlet
container security doesn't bring anything in case of an MVC framework like
Seam. And, since Seam 1.1 we can have a nice error page in case of an RBAC
exception, thus the view does not need to get access to the RBAC itself. This
is also in line with another security aspect: input validation. Via the
Hibernate annotations, they've also made the view "dumb" as it comes to input
validation. Anyone has opinion on this? Can anyone already shed some light on
which direction this is going to take? At JavaPolis someone of JBoss said they
where going to use a rules thingy for the Seam security... KISS please... we
already have a security system via EJB3, one should be enough.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994418#3994418
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994418
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
