We're definitely looking at doing something similar as well, so the interest level is definitely here though we haven't had the chance yet to define an implementation.
BTW, I noticed that Websphere v4 uses Struts for its Administrator Console! Does that mean that Websphere could be added to the "Powered by Struts" section of the Resources page? :-) Alex -----Original Message----- From: Adam [mailto:[EMAIL PROTECTED]] Sent: Monday, December 03, 2001 9:32 AM To: Struts Developers List Subject: Re: Proposal for form-based security 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
