It’s a Dangerous World: Adding Security - Stripes...and Java Web Development is Fun Again - page 319

Figure 14.3: A nicer (but still blunt) page for unauthorized access
If the user is not authenticated, we redirect to the Login page with the
URL to use after the user logs in. So, that will work as before. On the
other hand, when access is denied to an authenticated user, there's no
point in making them log in—we just return the 401 error code and
show the “Access Denied” page.
Using InstanceBasedSecurityManager
The second SecurityManager implementation included in Stripes-Secu-
rity is InstanceBasedSecurityManager , which extends J2EESecurityManager
and adds support for restricting areas of the application not only by
role name but also by an EL expression, like this:
@RolesAllowed("RoleName if ${expression}")
This grants access only if the user has the role RoleName and expression
evaluates to true .
Because InstanceBasedSecurityManager extends J2EESecurityManager and
overrides hasRole ( ) to add support for EL expressions, it adds another
method, hasRoleName ( ), which can be overridden to provide the logic
that determines whether a user has a role. So, to extend InstanceBased-
SecurityManager and not clobber its hasRole ( ) implementation, we have
to move our role-finding code from hasRole ( ) to hasRoleName ( ). Here is
the final MySecurityManager class:
Download email_35/src/stripesbook/nonext/MySecurityManager.java
package stripesbook.nonext;
public class MySecurityManager
extends InstanceBasedSecurityManager
implements SecurityHandler
{
@Override
protected Boolean isUserAuthenticated(ActionBean bean, Method handler) {
return getUser(bean) != null ;
}
@Override