[
http://www.stripesframework.org/jira/browse/STS-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11675#action_11675
]
John Newman commented on STS-363:
---------------------------------
we did something like this pretty quickly by subclassing the stripes form tag,
overriding writeFieldsPresentHiddenField (a predefined hook for what you really
need doesn't exist and should be added, lucky for us this method worked out ok
by coincidence).
As a quick aside I'd like to complain that any code that is possibly intended
to be subclassed should use protected variables, or better yet private
variables with protected getter methods! It sucks when the hook you need
isn't there, and you have to override an outer method, duplicate the code and
make your small change. But there's nothing worse than having the ideal hook
but not being able to read private variable in there! I think I've ran into a
few instances of this in stripes, as a potential java rule I'd argue that "Any
field marked private should provide a protected getter unless the class is
marked final."
Anyway, in the overriden method, we wrote out a hidden field <input
type="hidden" name="__token" value=" + getTokenSessionAttribute()
The token session attribute is generated once in a http session listener (on
create), it's the session id + system.currentTimeMillis(). There's a stripes
interceptor to run before binding, and if the method is "POST" and if the
posted token does not exist or does not match what is saved in the session we
know it's either a session timeout, or app restart.
If the token doesn't match it forwards (or streams json for ajax event) to a
warning page, with a link to <a href=""
onclick="window.location=window.location">refresh</a>
I'm not too familiar with how xss is done, does this approach prevent that as
well?
> 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
> Attachments: FormTickets.patch, FormTickets2.patch
>
>
> 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
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
