I have actually implemented something along the lines of the custom tags
for my project, although I have to admit I"Roled my own" security
without learning how to do J2EE security, and now am in the process of
retrofitting.
<getcare:security permission="directory">
<a href="aaaa">directory</a>
</getcare:security>
So we should replace "permission" with "role" but the concept is the same.
In the bottom example, you could get the same effect by having three
forms and actions, each of which only contains those fields that fall
into the appropriate roles. I would consider it an application of the
Refactoring "Replace conditional with polymorphism" since you are going
to end up with a lot of the custom tags around the areas that are
supposed to be non-visible.
One thing that might work, if the security levels go from most
restrictive to least restrictive, is to descend from a common base class
where everything is denied through intermediate classes with more levels
of security, to the most permissive.
EG:
Display an address book according to user state. If the user is
anonymous, give them a blank addess book. If the user is Recognized but
not authenticated, require them to log in or out. If the user is Logged
in, show them their personal address book.
This can be understood as both an application of the security proxy
pattern, and the state pattern, although it depends on how you implement it.
If you want to switch the action used for a given form, you can do it
based on a string, EI
<%String actionToUse=someBean.getActionToUse(); %>
<html:form action="<%= actionToUse %>">
where someBean could give you the action to use based on the user role.
LATOURNERIE Michel wrote:
>Hello Matt,
>
>Controling pages look and feel according to users roles is also exactely what I need
>and
>what I am currently working on.
>The solution you suggest is interesting because it is simple and covers most cases.
>
>However I am looking for a solution that
>1 - would keep the security information around the controller rather than around the
>forms,
>2 - could be extended so that the look and feel control could be based on session
>level
>or context level information other than pure security,
>3 - would be open enough so that almost any page layout information could change
>depending on security.
>
>My suggestion would be to:
>
>A) declare the fields configurations as form options rather than as security
>constraints,
>this would look like
>
><form-bean name="firstForm"
> type="org.apache.struts.webapp.example.FirstForm">
> <options>
> <option name="editableAddress"
> <fields="street,city,zip" type="write"/>
> <fields="adressUpdate" type="enable"/>
> </option>
> <option name="readOnlyAdress"
> <fields="street,city,zip" type="readOnly"/>
> <fields="adressUpdate" type="disable"/>
> </option>
> <option name="simplifiedReadOnlyAddress"
> <fields="street,zip" type="invisible"/>
> <fields="adressUpdate" type="invisible"/>
> </option>
> </options>
>
></form-bean>
>
>
>B) associate the security "roles" information to the action forward definition and to
>the
>form options, this would look like:
>
> <action path="/getAddress" type="GetAddressAction"
>roles="addressManagement,addressBrowsing,simpleViewing">
> <forward name="success" path="/address.jsp">
> <security roles="addressManagement" options="editableAddress" >
> <security roles="addressBrowsing" options="readOnlyAddress">
> <security roles="simpleViewing"
>options="simplifiedReadOnlyAddress">
> </forward>
> </action>
>
>C) provide form option reading/checking tags so that any JSP page code could rely on
>form
>options.
>
>
>I have not considered implementation yet. But though it would be more complex than
>your
>proposal, I have not identified design level obstacles.
>
>What do you think of my needs ? of my proposal ?
>
>thanks in advance.
>
>Michel
>
>
>
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
