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.
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.
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]>

Reply via email to