Thanks, but I should have mentioned, no JavaScript
allowed here.  At least not for something this mission
critical.

m

http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=73921

--- Mike Thompson <[EMAIL PROTECTED]> wrote:
> Everyone's favorite!!! ;)
> 
> you can always disable control-N via JavaScript ;)
> 
> in an onkeydown handler probably for a body tag.
> 
>     //check for control n
>     if (window.event.ctrlKey && window.event.keyCode
> == 78)
>     {
>             window.event.returnValue = false;
>             return false;
>     }    
> 
> 
>       --m
> 
> -----Original Message-----
> From: Pani, Gourav
> [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 28, 2003 3:50 PM
> To: 'Struts Users Mailing List'
> Subject: RE: Struts and the infamous IE multiple
> browser/same session
> problem
> 
> 
> have you considered creating a unique token to do
> session related updates?
> i don't think tokens can be transferred from one
> browser window to another
> though i could be wrong.
> 
> -----Original Message-----
> From: Michael Ruppin [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 28, 2003 3:47 PM
> To: Struts Users Mailing List
> Subject: Struts and the infamous IE multiple
> browser/same session
> problem
> 
> 
> I'm reconsidering my approach to this problem, in
> favor of something more elegant/more compatible with
> out-of-the-box Struts.  Anyone tackled this yet?
> 
> For those not aware, MS IE allows users to launch a
> browser against the same session via File/New/Window
> (Ctrl-N).  The issue is, if you have need to keep
> data
> in the session (which I do), a submission from one
> browser could grab and/or overwrite session data
> meant
> for the other browser.  This can lead to data
> integrity problems and other weirdness.  Telling my
> user community not to use MS IE or it's Ctrl-N
> feature
> is not an option.
> 
> My current approach is to put a hidden random "key"
> into the HTML, and name the session attribute with
> that.  When one of the two browsers submits a
> request
> (Assuming, at this point, they've opened another)
> the
> session data is pulled by key, assigned a new key, a
> new copy is placed in the session named with the new
> key, and the new key is rendered  in the HTML
> response.  The old session data may or may not be
> removed, depending on whether or not it is
> acceptable
> for the browser with the old key to [gracefully]
> fail,
> how we choose to expire session data, and whether or
> not a means of dealing with stale data is supported
> by
> the model.
> 
> This works fine, but in doing so I've had to write
> my
> own methods for populating collections of forms
> which
> would have otherwise been taken care of for me by
> specifying session scope in struts-config.  Am I
> missing a better way?
> 
> m
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Calendar - Free online calendar with sync to
> Outlook(TM).
> http://calendar.yahoo.com
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to