Java Reference
In-Depth Information
Joe Asks. . .
Why Isn't the SecurityManager Implementation Loaded via
the Extension Packages mechanism?
All classes of the Stripes-Security plug-in are in the same pack-
age. This includes, among other things, the interceptor and two
SecurityManager
implementations. By adding that package to
the extensions, the interceptor is automatically loaded. But we
wouldn't want the two
SecurityManager
implementations to be
loaded as well. One, there must be exactly one implementa-
tion, and two, we have to be able to provide our own.
Putting the two
SecurityManager
implementations in separate
packages just to solve the extension packages issue would be,
well, rather lame. Besides, you'd still have to indicate one of
those packages in
web.xml
, so you wouldn't be saving any con-
figuration. Since you have to add a parameter either way, it
may as well just be the class that implements
SecurityManager
;
it's clear and explicit.
We'll tell Stripes-Security to use our security manager by configuring it
in
web.xml
:
<init-param>
<param-name>
SecurityManager.Class
</param-name>
<param-value>
stripesbook.nonext.MySecurityManager
</param-value>
</init-param>
Now that
MySecurityManager
is ready to go, we can use
@DenyAll
,
@Per-
mitAll
, and
@RolesAllowed
on action beans and event handlers to control
access rights. Here's how we grant access to
UserListActionBean
only if
the user has the
Administrator
role:
@RolesAllowed("Administrator")
public class
UserListActionBean
extends
BaseActionBean {
Just like that, people without the
Administrator
role are denied access
to
UserListActionBean
. It's simple and straightforward, and we're reusing
standard Java annotations instead of introducing new ones.
Search WWH ::
Custom Search