[
http://www.stripesframework.org/jira/browse/STS-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11672#action_11672
]
Andrew Jaquith commented on STS-363:
------------------------------------
After having built some proofs-of-concept, I have been re-thinking the approach
to this, for two reasons:
* the @PredecessorEvent idea was a decent first stab, but it's too rigid.
Because the same annotation type cannot mark up a method more than once, there
is no way to specify multiple predecessor events
* The cookie-based approach has some potential security issues that are harder
to exploit with form-generated tickets
Here's a revised approach. FormTag would write out a hidden parameter with a
unique "ticket" value, if all of the following conditions hold:
- the form's beanclass and event properties are set
- the target event handler method contains an annotation indicating that it
requires a ticket to process the event
That's the ticket-generation part. The ticket-inspection part would work
similarly to the way described above.
Thus, if we had a stripes:form element that looks like this:
<stripes:form beanclass="com.example.MyActionBean" event="bar">
...and the "bar" event handler contains (say) a @TicketRequired annotation,
like so...
@TicketRequired
@HandlesEvent("foo")
public Resolution foo() { ...}
...then the hidden param would be written.
That is much nicer and simpler. The annotation could also specify an "expires"
attribute that sets a timeout threshold for the ticket.
> Flow Control Token to prevent XSRF/double-posting
> -------------------------------------------------
>
> Key: STS-363
> URL: http://www.stripesframework.org/jira/browse/STS-363
> Project: Stripes
> Issue Type: New Feature
> Components: Context Management, Tag Library
> Reporter: Sylvan von Stuppe
> Priority: Minor
>
> I would love to have a built-in feature for generating a random token,
> putting this token into the user's session, then be able to have the same
> token as a hidden form value on subsequent pages. When a user submits a
> page, the token the send is checked against the one in the session (possibly
> as part of the @Validate annotation?) and if they don't match, the user is
> sent to a different page. If they do match, the action continues.
> I attempted to do this as part of a BaseActionBean class, but it quickly fell
> apart because the default binding is for the form to be populated by what the
> user submitted, not what's in the bean. So the first request would work
> because the user didn't submit anything, the attribute is gotten from the
> bean (which would generate the new token, set it in the session, and return
> it), and was presented on the form. But on subsequent requests, the value
> came from what the user submitted (the old token), rather than from the bean.
> So I ended up having to use a vanilla <input> tag with ${} to get the value
> out of the request scope.
> I don't know of the most "Stripes friendly" way to implement this, but I
> suspect it would require changes to the ActionBeanContext and certainly the
> tag libraries.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
