Yeh. Good point. Mind you , if we have no users, then we dont need a client side, so we could eliminate all that annoying validation, and rendering of the screen, and such like.... :-)
-----Original Message----- From: Michael Delamere [mailto:[EMAIL PROTECTED]] Sent: Monday, September 09, 2002 18:57 To: Struts Users Mailing List Subject: Re: [Tokens][2] Where can I find more information.... I donīt quite agree (sorry) because I want to solve the problem without javascript. I hate javascript and always try to do without it :-) Regards, Michael ----- Original Message ----- From: "Andrew Hill" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Monday, September 09, 2002 12:36 PM Subject: RE: [Tokens][2] Where can I find more information.... > I guess the real trick would be to eliminate the users altogether, as they > seem to be the source of most problems. > hehe. Maybe I should try and divert the "[OT] JavaScript auto-submit form" > thread to this dicussing this idea ;-> > > -----Original Message----- > From: Michael Delamere [mailto:[EMAIL PROTECTED]] > Sent: Monday, September 09, 2002 18:40 > To: Struts Users Mailing List > Subject: Re: [Tokens][2] Where can I find more information.... > > > > Of course its only a problem if one tries to accomodate multitasking > users, > > so if users can be trained not to play silly buggers with multiple windows > > everything should work fine. > > Wishful thinking.... :-) > > > ----- Original Message ----- > From: "Andrew Hill" <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > Sent: Monday, September 09, 2002 12:21 PM > Subject: RE: [Tokens][2] Where can I find more information.... > > > > Yep. Thats what I thought. :-( > > There are actually quite a few things in struts that seem to have this > issue > > in relation to constant session keys. > > > > Single browser window seems to be an assumption most struts apps make, but > > it would be nice if the framework provided more support for multiple > windows > > (keeping track of which is quite a nightmare!). > > > > -----Original Message----- > > From: Jon.Ridgway [mailto:[EMAIL PROTECTED]] > > Sent: Monday, September 09, 2002 18:09 > > To: 'Struts Users Mailing List' > > Subject: RE: [Tokens][2] Where can I find more information.... > > > > > > Hi Andrew, > > > > Read your post properly this time; umm good point the same key is used and > > one would over right the over, invalidating the first... So yes it looks > > like they would interfere... > > > > Jon Ridgway > > > > > > -----Original Message----- > > From: Jon.Ridgway [mailto:[EMAIL PROTECTED]] > > Sent: 09 September 2002 11:00 > > To: 'Struts Users Mailing List' > > Subject: RE: [Tokens][2] Where can I find more information.... > > > > Hi Andrew, > > > > The generateToken method in Action.java generates a unique token each time > > saveToken is called. > > > > Jon Ridgway > > > > > > -----Original Message----- > > From: Andrew Hill [mailto:[EMAIL PROTECTED]] > > Sent: 09 September 2002 10:23 > > To: Struts Users Mailing List > > Subject: RE: [Tokens][2] Where can I find more information.... > > > > Hope you will excuse me stealing this topic for a related question - I > added > > a [2] tag to indicate this ;-) > > > > As far as I can see the key under which the token is saved is a constant. > > What happens if another browser window is also open on some other form (in > > same session) and the user is trying to submit something there to another > > action that also users tokens. (This is one of those anoying users who > opens > > fifty billion windows and does stuff in one window while waiting for > > submission / page loading in another window to complete) > > > > Wont the two interfere? > > > > ie: > > User fills in form in window A and submits. > > While waiting for that to complete, user enters stuff in window B (for a > > different form or record) and submits that. > > What happens to the tokens here? > > > > > > btw: heres a copy of the msg Michael refers to in the archive (for those > who > > havent time to load the web page) > > > To deal with resubmits, the most important issue is to avoid updating > the > > > database twice when the user accidentally resubmits the same form. > Struts > > > has a feature called "transaction control tokens" that help you avoid > > > this, which is very simply used as follows: > > > > > > * In the Action that sets up your input form (i.e. before you forward > > > to it), execute the following > > > > > > saveToken(request) > > > > > > to save a special value in the user's session that will be used in > > > the next step. > > > > > > * In the Action that receives the form and updates the database, add > > > the following logic before you do the update: > > > > > > if (isTokenValid(request, true)) { > > > ... this is a resubmit, so go display an error ... > > > } > > > > > > The "true" parameter causes the token to be removed from the session > > > so that it doesn't interfere with subsequent form submits. > > > > > > This way, the submit will work the first time, but fail on any > accidental > > > or on-purpose resubmit, and you avoid adding the information to the > > > database twice. It also prevents the user from navigating directly to > the > > > "myDB.do" URL without going through your normal setup actions -- because > > > the transaction token would not have been placed in the session, so the > > > isTokenValid() test would fail. > > > > > > Craig > > > > -----Original Message----- > > From: Michael Delamere [mailto:[EMAIL PROTECTED]] > > Sent: Monday, September 09, 2002 17:25 > > To: Struts Users Mailing List > > Subject: Re: [Tokens] Where can I find more information.... > > > > > > ok, I found this which pretty much helped me understand what is going on: > > > > http://www.mail-archive.com/struts-user@jakarta.apache.org/msg35501.html > > > > > > However I still have a problem: > > > > In my showProductsAction I have the line: saveToken(request); > > > > Then next option would be to click "add to cart" in which case I would go > to > > the CartAction accordingly. In my CartAction I check the token: > > > > =============================== > > if (isTokenValid(request, true)) { > > System.out.println("TOKEN IS VALID"); > > } > > else { > > System.out.println("TOKEN IS NO LONGER VALID"); > > } > > =============================== > > > > Is the above code assumption correct or am I misinterpreting something? > > Because when I submit "add to cart" I always jump into the else block! > > > > > > Regards, > > > > Michael > > > > > > > > ----- Original Message ----- > > From: "Michael Delamere" <[EMAIL PROTECTED]> > > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > > Sent: Monday, September 09, 2002 9:40 AM > > Subject: [Tokens] Where can I find more information.... > > > > > > > Hi, > > > > > > I posted a thread last week about having caching problems and that my > > > shopping cart was being incremented by 1 everytime somebody refreshed > the > > > browser. > > > > > > The answer I got was that one could use tokens. Sounds like a great > idea! > > > So I had a look at the struts-example to find out what itīs about but to > > be > > > honest I donīt understand exactly what is going on. > > > > > > I tried implementing the code almost exactly as it was done there and it > > > keeps on telling me that my token is invalid. The problem I have here > is > > > that I donīt know what it means or what I have to do to correct this. > > > > > > 1. Does anyone know where I can find more information on these tokens? > > > > > > 2. Would it not be a good idea to include this in the struts-config > > action > > > configuration, > > > i.e. token="true"? > > > > > > Any help would be really appreciated! > > > > > > Thanks, > > > > > > Michael > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > The contents of this email are intended only for the named addressees and > > may contain confidential and/or privileged material. If received in error > > please contact UPCO on +44 (0) 113 201 0600 and then delete the entire > > e-mail from your system. Unauthorised review, distribution, disclosure or > > other use of this information could constitute a breach of confidence. > Your > > co-operation in this matter is greatly appreciated. > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > The contents of this email are intended only for the named addressees and > > may contain confidential and/or privileged material. If received in error > > please contact UPCO on +44 (0) 113 201 0600 and then delete the entire > > e-mail from your system. Unauthorised review, distribution, disclosure or > > other use of this information could constitute a breach of confidence. > Your > > co-operation in this matter is greatly appreciated. > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
