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]