Frye, Dave wrote:
> I like the use of your check to examine the previous path, however, it must
> be used in combination with a command token to ensure that user has not gone
> back to an old page that happens to match the current path. Your check will
> certainly catch the case where they hit the back button once and re-submits,
> since their current path would be virtually guaranteed to be different than
> that needed for the previous submit. But say user goes to through pages A,
> B, C and back to A again. Now, the user backs up 3 pages to the previous A
> screen and submits again. It may not be likely to occur, but couldn't this
> scenario pass the previous path check? I think you still need to use a
> token if you cannot prevent cached pages.
Well, I think the basic question is: What do I want to achieve with my little
extension? I wanted to prevent the user from doing a few things which we had to
cope with in any web project we did up to now:
1. Don't let the user push the reload button which could lead to a duplicate
database entry (if we are speaking of an application where a user generates some
type of database content).
2. Being easily able to build a chain of web pages which have to be executed
directly after each other, e. g. A->B->C, where A is the action to display a
form where the user can input some comment (e. g. for a discussion board), B is
the preview for his new comment, and C is the message which says that his
comment was successfully entered to the board. Using the extension allows me to
prevent the user from executing action B without having executed action A
directly before, i. e. I can rely on some facts like: the right values have
already been stored in the session, i. e. I am in the right session state, and
so on.
3. Being able to easily chain single actions on the server A->B->C, where A gets
the client request, does a server side forward to B which finally forwards to C
which sends the response to the client. The examination of the previous path
easily allows to prevent the user from directly executing Action B or C by
typing in their URL.
But I agree there may be cases when you want to enhance the checks with a token.
My idea how this could be accomplished is this:
- Create a unique token automatically in each action.
- Automatically include it in any request that might come from the next page
(per URL-Rewriting in struts-html.link tag or in forms with the struts-html.form
tag)
- and check it in the next action.
But this definitely would need to be included directly in struts, because you
have to modify the link and form tags, while my current extension can easily be
used as an add on.
> While it is convient to implement security and logging in your GenericAction
> class, it potentially leads to an unruly hierarchy of Action super classes
> that deal with the request dispatching process. I belive that the
> Dispatcher is the place to handle all aspects of dispatching application
> level requests. Ideally, the Dispatcher would provide a pluggable Chain of
> Responsibility-like pattern that allows for configurable security, loggin,
> etc. without impacting the Actions. Tomcat has different such a patterns
> handling http requests. Struts could implement one that works at the
> application level to provide security, logging and potentially other uses.
The only reason I subclassed the struts Action class was to avoid patching
struts severely. There would be no need for the GenericAction class, if the code
enhancements were direcly done to the Action class.
>
> didge
>
--- Matthias
>
> -----Original Message-----
> From: Matthias Bauer [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 07, 2001 3:44 AM
> To: undisclosed-recipients
> Subject: Re: Work flow RFC
>
>
> Hi everybody,
>
> there is a mail I already sent to this list with another subject, because
> somebody asked for it.
>
> There is some very simple extension to Struts which I implemented, because I
>
> needed to have at least a minimum workflow support.
>
> Maybe you want to check out this little extension and reuse at least some of
> the
> ideas.
>
> Here is the mail text I am talking about. I also attached the files again.
>
> --- Matthias
>
>
> *******************************************************************
>
> Hi everybody.
>
> There were quite a few requests to share the code I talked about in an
> earlier
> mail with this subject.
>
> The code subclasses some struts classes and provides the following
> enhancements:
>
> 1. Control flow. For each action you can specify the action which must be
> executed directly before. Thus, you can easily prevent someone from hitting
> the
> reload button or using the browser's back button and submit a form for the
> second time. The mechanism I chose can replace the token mechanism provided
> by
> struts and brings some further enhancements. A small example: An action
> displayLogon displays the logon page of a web application. The next action
> logonAction defines the action displayLogon as the previous action. An
> exception
> is raised (and causes a forward to an appropriate error page) when the
> previous
> action is something else then displayLogon.
> 2. User authentication: For each action you can specify an object which does
> a
> check whether the user is authenticated to execute this action. Together
> with
> the paradigm (which I would warmly suggest to anybody) to only display jsp
> pages
> through actions like displayXXX you can easily do fine grained authorization
> checks for your whole webapp.
> 3. Maintenance mode: If your web-site is currently under maintenance set the
> debug level to -1 and all the actions automatically forward to a maintenance
> page, which should display an appropriate message the the user.
>
> Now, here is a brief code description. For details please have a look at the
> source code which (I hope) is richly commented.
>
> GenericAction
> =============
>
> Extends Action and is the class from which all other Actions need to be
> derived.
> It does the follwing:
>
> 1. Check if we are in maintenance mode. If we are, then forward to the
> maintenance page.
> 2. Check for the authentication object (of type GenericAuthentication) which
> is
> specified by the action's parameter "authtype". If authentication fails,
> forward
> to an authentication exception action, which should display a page with a
> reasonable message.
> 3. Check whether the action attribute "prevpath" matches the current
> prevpath
> value which was stored by the (directly before executed) GenericAction in
> the
> user's session. If it does not match forward to a control flow exception
> action.
> 4. Now call the method "performAction" (which needs to be overridden by all
> actions that subclass GenericAction). If debugging is switched off, all
> exceptions thrown in this method are catched an a forward to an exception
> action
> is done.
> 5. Update the session variable which stores the prevpath value, so it holds
> the
> correct value when the next action checks it.
>
>
> AuthenticationException
> =======================
>
> Exception thrown, when trying to access a resource that you are not allowed
> to
> access.
>
>
> GenericAuthentication
> =====================
>
> Interface that should be implemented by classes which provide authentication
> checks, which are used by GenericAction.
> Please note that GenericAction uses only a single instance of each
> authentication object. So you have to be very careful when you use data
> members.
> Normally only the single method check is provided, which does not work on
> any
> object's variables.
>
>
> AnyUserAuthentication
> =====================
>
> Example for an authentication class which implements the interface
> GenericAuthentication.
>
>
> ApplicationMapping
> ==================
>
> Implementation of enhanced ActionMapping.
> It defines the following custom properties:
> - prevpath - The context-relative URI of the previous action. This enables
> the
> Action-Classes to compare this value to the value they can easily track.
> This
> enables rudimentary flow control checks.
> - authtype - The name of the authentication class which checks if the user
> is
> allowed to execute the mapping's action.
>
> For the ApplicationMapping to become effective you have to change the
> parameter
> mapping in web.xml like this:
> <init-param>
> <param-name>mapping</param-name>
> <param-value>ApplicationMapping</param-value>
> </init-param>
>
>
>
> struts-config.xml
> =================
>
> The struts configuration file can then look like this:
>
> ============================================================================
> =======
>
> <!-- ========== Global Forward Definitions ==============================
> -->
> <global-forwards>
> <forward name="authenticationexception" path="/authenticationException.jsp"
> />
> <forward name="maintenance" path="/maintenance.jsp" />
> <forward name="controlflowexception" path="/controlFlowException.jsp"/>
> <forward name="exception" path="/exception.jsp" />
> </global-forwards>
>
> <!-- ========== Action Mapping Definitions ==============================
> -->
> <action-mappings>
> <!-- Display login -->
> <action path="/displayLogin"
> type="SuccessAction">
> <forward name="success" path="/index.jsp" />
> </action> <!-- Execute the login -->
> <action path="/loginAction"
> type="LoginAction"
> name="loginForm"
> scope="request"
> input="/index.jsp">
> <set-property property="prevpath" value="/displayLogin"/>
> <forward name="success" path="/displayPasswordChange.do" />
> </action>
>
>
> <!-- Display change password page -->
> <action path="/displayPasswordChange"
> type="SuccessAction">
> <set-property property="authtype" value="AnyUserAuthentication"/>
> <forward name="success" path="/passwordChange.jsp" />
> </action>
>
> <!-- Change password action for an already registered user -->
> <action path="/passwordChangeAction"
> type="PasswordChangeAction"
> name="passwordForm"
> scope="request"
> input="/passwordChange.jsp">
> <set-property property="authtype" value="AnyUserAuthentication"/>
> <set-property property="prevpath" value="/displayPasswordChange"/>
> <forward name="success" path="/passwordChangeSuccess.jsp" />
> </action>
> </action-mappings>
>
> ============================================================================
> =======
>
> See what happens?
>
> - You are not allowed to execute displayPasswordChange or
> passwordChangeAction,
> when you are not correctly logged in. The framework does the check for you.
> - passwordChangeAction and loginAction are only executed, if
> displayPasswordChange or displayLogin respectively, have been executed
> directly
> before.
>
> I found these enhancements very helpful for my web applications, because it
> deals with some basic issues you always have to solve in webapps. Therefore
> I
> would like to see these enhancements incorporated into the standard struts
> framework. I plan to propose this officially after Struts 1.0 has been
> released.
> I am sending it to the list now, because some of you asked for it. In the
> meantime I would appreciate any feedback (both positive or negative ones).
>
> Hope you have fun,
>
> --- Matthias
>
>
> *******************************************************************
>
>
>
> Jonathan Asbell wrote:
>
>
>>Is there anyone on the list that actually HAS experience developing with
>>workflow engines?
>>
>>----- Original Message -----
>>From: "Rey Francois" <[EMAIL PROTECTED]>
>>To: <[EMAIL PROTECTED]>
>>Sent: Wednesday, June 06, 2001 4:40 AM
>>Subject: RE: Work flow RFC
>>
>>
>>
>>
>>>Another possibility is to develop extensions for the TogetherJ CASE tool.
>>>
>>>
>>It
>>
>>
>>>is entirely written in Java, therefore can run on most platform, and from
>>>
>>>
>>my
>>
>>
>>>understanding it is possible to define new diagram types and patterns.
>>>
>>>This may not directly relate to workflow, but we have in our team created
>>>the concept of a request servicing diagram which is a class diagram
>>>representing the objects involved in servicing a request. Particularly on
>>>this diagram we display the request object and the action it is mapped to.
>>>Although we have not done it yet, it is quite possible to develop a
>>>
>>>
>>pattern
>>
>>
>>>that generates the corresponding action mapping entry in the
>>>struts-config.xml, and vice-versa.
>>>
>>>François Rey
>>>Financial WebSuite
>>>Capco
>>>http://www.capco.com/
>>>
>>>
>>>-----Original Message-----
>>>From: Craig Tataryn [mailto:[EMAIL PROTECTED]]
>>>Sent: 05 June 2001 20:06
>>>To: Jonathan
>>>Cc: [EMAIL PROTECTED]
>>>Subject: Re: Work flow RFC
>>>
>>>
>>>Is this a workflow editor or just a configuration editor (which would be
>>>nice
>>>for struts)?
>>>
>>>craig.
>>>
>>>Jonathan wrote:
>>>
>>>
>>>
>>>>Again, Ive got to say look at the Barracuda project. They have one of
>>>>
>>>>
>>>these
>>>
>>>
>>>>gui configurers. Check it out at
>>>>http://barracuda.enhydra.org/Barracuda/GetBConfig.event
>>>>
>>>>----- Original Message -----
>>>>From: "Craig Tataryn" <[EMAIL PROTECTED]>
>>>>To: <[EMAIL PROTECTED]>
>>>>Sent: Tuesday, June 05, 2001 12:28 PM
>>>>Subject: Work flow RFC
>>>>
>>>>
>>>>
>>>>>Hi, I would like your comments for the workflow item on our TODO list.
>>>>>Currently this is how I've envisioned the workflow project:
>>>>>
>>>>>1) A nice GUI type Applet or Application that has visual constructs
>>>>>which can be connected in a Visio type manner to create an Activity
>>>>>diagram or some other type of flow diagram.
>>>>>
>>>>>2) This diagram will be persisted in an XML file which holds meta data
>>>>>for the elements in diagram (position, type of construct (controller,
>>>>>flat html page, cgi script, flow arrow, etc..)).
>>>>>
>>>>>3) The diagram can be exported to a struts config file via XSLT (i.e.
>>>>>workflow.xml -> workflow2struts.xsl -> struts-config.xml)
>>>>>
>>>>>4) A diagram can also be imported from a struts-config.xml file via
>>>>>
>>>>>
>>XSLT
>>
>>
>>>>>(i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of
>>>>>course some sort of "pretty layout" code would have to be used to
>>>>>un-jumble the mess of constructs that are sucked out of the
>>>>>struts-config.xml file (i.e. take a guess at proper positioning
>>>>>information).
>>>>>
>>>>>The GUI should employ some sort of extensibility mechanism like BSF
>>>>>(http://oss.software.ibm.com/developerworks/projects/bsf) or Bean
>>>>>
>>>>>
>>Shell
>>
>>
>>>>>(http://www.beanshell.org/) to allow users to plug-in their own
>>>>>functionality (i.e. validation code) without jeopardizing the core
>>>>>
>>>>>
>>code
>>
>>
>>>>>(what I call the Emeril Lagasse technique -- BAM!).
>>>>>
>>>>>I realize this is a very high level look at the TODO but I think as we
>>>>>get more comments we will get more granular and can start dishing out
>>>>>segments.
>>>>>
>>>>>Let me know what you think.
>>>>>
>>>>><tataryn:craig/>
>>>>>
>>>************************************************************************
>>>The information in this email is confidential and is intended solely
>>>for the addressee(s).
>>>Access to this email by anyone else is unauthorised. If you are not
>>>an intended recipient, you must not read, use or disseminate the
>>>information contained in the email.
>>>Any views expressed in this message are those of the individual
>>>sender, except where the sender specifically states them to be
>>>the views of Capco.
>>>
>>>http://www.capco.com
>>>***********************************************************************
>>>
>>>
>>>
>
> y
>
