synchronization strategies

[Yaroslav Novytskyy <sp...@n-ix.com.ua>]

Hello!

OK, first try failed :) Am I allowed to start it over? :)

Would you like (in your web application) to add a value to a list (eg a 
row to a table in a DB)?

If yes, then......
Your create a Page and an Action. Page contains a html:form with a field 
- html:text. Action takes this field and calles something like 
myDB.theTable.add(field). This works! supper! but... what if user is 
going to press Refresh? Shit! ...field is added once more. User presses 
F5 again and field is added once again! Is this an undesired functionality?

(*if _enyone_ knowes of _any_ alternatives, _please_ let me know!*)

If yes, then.......
I use this method : I create two actions (editPrepare and editSubmit) 
and a jsp page (for showing the form). (This my solutionis based on 
MappipngDispatchAction.) So the process lookes like this editPrepare 
calls saveToken(), then the page is displayed (with additional hidden 
field in the form with a value of token) and editSubmit action checks 
and resets the token with isTokenValid(request, true). If the token is 
valid myDB.theTable.add(field) is executed else nothing (or error of 
synchronization, if you would like) This workes good, but in a closer 
look there is a problem of hiding results of a "submit"-action on form 
repost. And... this concept does not work for "delete"-actions, couse 
they do not have "prepare"-action. Would you like to make this strategy 
problemless and make a standard automated synchronization pattern of it?

(*I see automation in writing the same execute (named other way) method, 
but not bothering that it will be executed more then once if this is 
undesirable*)

If yes, then.........
There is a solution (even ready-made) described (and coded) here 
http://www.javaworld.com/javaworld/javatips/jw-javatip136.html (look at 
code in attachment not in the article, though the concept is the same). 
With some changes and modifications this can be used with my strategy. I 
do like this: I extend my own SynchroMappingDispatchAction on top of 
changed and adopted SynchroAction and at the moment am playing with it 
(testing, debugging, modifying, rewriting) and would appriciate _any_ 
comments or thoughts about the whole of this....

(*In the case someone is interested I will post here info about my 
further experimets.*)

With best regards
Yaroslav Novytskyy


Yaroslav Novytskyy wrote:
> Hello!
> 
> Iwanted to implement a token protection in my app and first found 
> http://www.jguru.com/faq/view.jsp?EID=779112 from Ted Husted.
> 
> Then I wnted to automate the precess, so I programmed myself a little, 
> but then looking over the internet once more for token-based flow 
> controll protection automation and came across 
> http://www.javaworld.com/javaworld/javatips/jw-javatip136.html article 
> about SynchroAction (P.S. the code in the article is outdated, but it 
> has a link to an "up-to-date" code in resources section). And I liked 
> the idea of it, but I'm working with MappingDispatchAction so I succeded 
> in creating SynchroMappingDispatchAction. But here I've got a problem: 
> in such an architecture an infinite loop can happen finishing in 
> StackOverwlow.
> 
> Can you please comment... maybe there is an ready to use decision... 
> pattern... code... ?
> 
> With best regard
> Yaroslav Novytskyy
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 

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

Re: synchronization strategies

[ichy <ic...@gmail.com>]

 hi, Yaroslav.
 i don't have any sample codes to post.
but this is what i usually care.
 webapps i build are most of the time e-commerce 
apps and i have the same problem when a user
submit the final order ( that is the transaction i
need to protect ).
 there are two things i care.
 1. i wanna protect honest customers from accidental multiple submits
 2. i wanna protect database integrity from
malicious users.
 so, i use javascript to prevent multiple submits
as client-side solution. for server-side, i use
Post-Redirect- Get-like solution as you mentioned.
( two actions for setup and submit). and also
token.
 i think this is pretty much enough to protect honest
users. and for malicious users, i don't care as long
as database integrity is not broken.
 so, i prefer forwarding to error page explaining possible reasons why error 
page showed up 
to showing success page or for delete,
error page saying "no such entity with id X" on 
second submit. 
 in those cases, users cannot see the result of the 
first submit. but most of the time customers can
understand what happend ( if they are the 
malicious, truely they knew ).
 i hope this wil cover some of your interest.
 regards
ichy
 and for the sychronization, i wonder if that leads to
DoS attack or not..