struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Struts Newsgroup (@Basebeans.com) <str...@basebeans.com>
Subject Re: Design Advice: Using DispatchAction
Date Tue, 23 Jul 2002 15:40:02 GMT
Subject: Re: Design Advice: Using DispatchAction
From: "Vic C." <vic@basebeans.com>
 ===
Robert Taylor wrote:
"The problem I am running into is that pre-processing
requirements vary within the common event groupings. For example,
let's say eventGroupA handles events 1, 2, 3, and 4.
Events 3 and 4 require that the user be logged in before
any processing occurs, but events 1 and 2 don't."

Hate to be a broken record....
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html#JDBCRealm
Any container does it!!!!

The web container does that for you already!
Some should go to /do/*
Some should go to /do/portected/*
and then set up you web-xml *not struts* :
    <security-constraint>
         <web-resource-collection>
             <web-resource-name>Secure</web-resource-name>
             <url-pattern>/do/port/*</url-pattern>
         </web-resource-collection>
         <auth-constraint>
             <role-name>guest</role-name>
             <role-name>enhanced</role-name>
             <role-name>manager</role-name>
         </auth-constraint>
         <user-data-constraint>
             <description>SSL not required</description>
             <transport-guarantee>NONE</transport-guarantee>
         </user-data-constraint>
     </security-constraint>
     <login-config>
         <auth-method>BASIC</auth-method>
         <realm-name>default</realm-name>
     </login-config>
See some are portected.
Here is a link on web.xml:
http://edocs.bea.com/wls/docs61/webapp/web_xml.html

Full working example (and a live online struts webex tutorial in a few 
days at.... you guessed it http://basicportal.sourceforge.net ). The 
example sometimes authoticates and sometimes it does not, and it passes 
the rediriect and parametars for you.
See, already done in web.xml, and 0 code no matter how complex.
Then if you want more you do servlet api, getuserpricipal, snipet:
	String authenUser = ae.getReq().getUserPrincipal().getName(); //security
	UserBean userBn = new UserBean();
	userBn.find(authenUser);
	String userid = userBn.getId();
	frm.setUserid(userid);

Here is a link on servlet api
http://java.sun.com/webservices/docs/ea2/api/


Some of these topics are a bit of a pre req for Struts, and one is JAAS:
http://suned.sun.com/US/certification/java/exam_objectives.html#web


hth,
Vic

ps: The struts example should not be login, one day...


> I'll try to keep this as short as possible.
> 
> Background:
> I have various groupings of common events in my web app where
> I would like each grouping of common events handled by a single
> Action class. The DispatchAction class allows me to
> do this. I want to do this because in my scenario,
> the Action classes are simple proxies to my business
> tier and are not reusable and I would like to keep
> the number of Action classes I have to create to a minimum.
> 
> 
> Problem:
> The problem I am running into is that pre-processing
> requirements vary within the common event groupings. For example,
> let's say eventGroupA handles events 1, 2, 3, and 4.
> Events 3 and 4 require that the user be logged in before
> any processing occurs, but events 1 and 2 don't.
> 
> 
> An idea: Assertions
> What if there was a way to declaratively define an ordered
> list of assertions that must be true before any processing
> occurs for an action mapping. Assertions would be processed
> in the order in which they appear in the action mapping
> and would return an ActionForward only if it failed else it
> would return null indicating that the assertion passed and
> to continue processing. Any errors or messages would be
> revealed to the user via ActionErrors or ActionMessages stored
> in the appropriate scope. An Assertion would have access to
> the action mapping so it could leverage lookups for locally
> or globally defined forwards. An Assertion would implement
> a Command pattern and have a single method assert()
> into which the RequestProcessor would be passed the ActionForm,
> ActionMapping, HttpServletRequest, and HttpServletResponse.
> Basically the same arguments as Action.execute().
> 
> 
> Example struts-config with assertions:
> 
> <assertions>
>    <assertion name="authenticated"
> type="com.company.web.assertion.SomeAssertion"/>
>    <assertion name="isAdministrator"
> type="com.company.web.assertion.AnotherAssertion"/>
> </assertions>
> 
> <action
>    path="/user/account/create"
>    type="com.company.web.account.UserAccountController"
>    name="userAccountForm"
>    scope="request"
>    validate="true"
>    input="/WEB-INF/user/account/create.jsp"
>    parameter="create">
>    <assert name="authenticated"/>
>    <assert name="isAdministrator"/>
>    <forward name="success" path="/WEB-INF/user/account/detail.jsp"/>
>    <forward name="failure" path="/WEB-INF/user/account/error.jsp"/>
> </action>
> 
> 
> 
> Example of Assertion.assert():
> 
> public ActionForward assert(ActionMapping mapping,
>     ActionForm form, HttpServletRequest request,
>     HttpServletResponse response) throws Exception;
> 
> 
> This solution seems to fit my needs, but I'm interested in any feed back on
> it.
> Good or bad. Does it suck? Is there a better way to accomplish my goal? Am I
> way
> off track? Am I close? Am I making things too complex? Is this idea kludgy?
> 
> 
> 
> robert
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message