Nope..the same cookie exists across windows that are created from the root
browser. A new browser instance gets a different session id.
> -----Original Message-----
> From: Ariel Pablo Klein [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 14, 2001 12:16 PM
> To: [EMAIL PROTECTED]
> Subject: Re: User hits STOP button, then submits again..how to prevent
> thi s or provide a solution?
>
>
> Sorry, but...... cookies? I never tried it too much, but I think that
> cookies have to works within windows. I haven't time to try it right
> now.
>
> -----Original Message-----
> From: A mailing list about Java Server Pages specification
> and reference
> [mailto:[EMAIL PROTECTED]] On Behalf Of Duffey, Kevin
> Sent: Tuesday, August 14, 2001 3:24 PM
> To: [EMAIL PROTECTED]
> Subject: Re: User hits STOP button, then submits again..how to prevent
> thi s or provide a solution?
>
>
> Ok..tried it. Doesn't work. When you use File -> New -> Window, or
> right-click and use Open link in new window, it continues to show the
> JSP page it came from..and not null. That is too bad..that would have
> been a kewl way to control it. Wonder if there is another method to do
> this with.
>
>
> > -----Original Message-----
> > From: Jon Garry [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, August 14, 2001 2:10 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: User hits STOP button, then submits again..how
> to prevent
>
> > thi s or provide a solution?
> >
> >
> > The HTTP_REFERER environment variable gives the URL of the page you
> > was viewing before the one you are currently viewing.
> >
> > Therefore, if you do a 'new window', there would be no
> refering page,
> > so HTTP_REFERER would be blank/null but if you were browsing
> > round a site then
> > HTTP_REFERER would always contain a URL.
> >
> > I think the best way of trying this is to write some code.
> Write a few
>
> > interlinking JSPs to display the HTTP_REFERER and then try
> doing a new
>
> > window - hopefully it should be blank!
> >
> > -----Original Message-----
> > From: Kevin Duffey [mailto:[EMAIL PROTECTED]]
> > Sent: 14 August 2001 10:09
> > To: [EMAIL PROTECTED]
> > Subject: Re: User hits STOP button, then submits again..how
> to prevent
>
> > thi s or provide a solution?
> >
> >
> > I have never looked into that to be honest. However, I know
> when I am
> > on one page, and I open a new window, it shows me the same page in
> > the new window.
> > So I am not sure how the HTTP_REFERER would be blank...can
> > you explain how
> > you think this might be?
> >
> > > -----Original Message-----
> > > From: A mailing list about Java Server Pages specification and
> > > reference [mailto:[EMAIL PROTECTED]]On Behalf Of Jon Garry
> > > Sent: Tuesday, August 14, 2001 1:20 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: User hits STOP button, then submits again..how
> > to prevent
> > > thi s or provide a solution?
> > >
> > >
> > > Kevin,
> > >
> > > Just an idea, but to stop someone opening up a new
> window, could you
>
> > > not check the HTTP_REFERER attribute?
> > >
> > > If a new window has been opened, it should (as far as I
> am aware) be
>
> > > blank whilst your 'legitimate' window would have some value
> > in there -
> > > the URL of the old page.
> > >
> > > Jon
> > >
> > > -----Original Message-----
> > > From: Duffey, Kevin [mailto:[EMAIL PROTECTED]]
> > > Sent: 13 August 2001 21:24
> > > To: [EMAIL PROTECTED]
> > > Subject: User hits STOP button, then submits again..how to prevent
> > > this or provide a solution?
> > >
> > >
> > > Hi al,
> > >
> > > I am almost positive the answer is no, but I thought I'd
> > see if anyone
> > > has come up with a solution. All too often, we have some
> users that
> > > submit a large query, then hit the STOP button on the
> browser, then
> > > change something and submit again. In the meantime, their original
> > > query is still executing on the server-side. Sure..Orion throws an
> > > exception when it tries to send the response back and the
> connection
>
> > > to the browser is gone. But I am wondering if there is any
> > way at all
> > > to just kill that particular request. Like..is there some
> > way the app
> > > server or web server can send pings every say, 100ms to the
> > browser to
> > > make sure its connection is still alive..and if
> > > not, just kill the request in some manner. Perhaps by
> > having a special
> > > interface that an application can implement, so that a particular
> > > method can be called if the server detects that the connection to
> > > the
> > browser is dead
> > > before the response has gone back. In this way, that method
> > call can get
> > > ahold of the session, and perhaps get ahold of a connection
> > being used,
> > > close it, etc.
> > >
> > > Ofcourse, you can use some client-side javascript to "disable" a
> > > button after its been clicked. We have done this, and we
> > also inserted
> > > a "transition" page in particular areas where long queries might
> > > occur. In this case, the user sees an animated gif and a
> > message that
> > > tells them not to hit stop or back. Ofcourse..you're
> still going to
> > > get those users that do this. My personal opinion is that
> > if they call
> > > in, we tell them they are stupid, they should unplug
> their computer
> > > and quit their job because they can't follow instructions.
> > > Ofcourse..that wont fly, especially if they are a big
> money client.
> > > Besides, its ethically wrong to screw
> > your clients over.
> > > ;)
> > >
> > > So, one possible idea I have had is to do the following.
> > Each user has
> > > a session when they log in. Upon any request, a "flag" is
> set in the
>
> > > session of that user, indicating a transaction is starting. If the
> > > user hits STOP, then submits while that transaction is
> > still going on,
> > > the server will see the flag is set, and send back a response
> > > indicating that a transaction is currently happening and
> > they have to
> > > wait for it to be done before another submit can occur. There is a
> > > plus side to this..it prevents any user to doing more than
> > one thing.
> > > The down side is, it is possible using the File
> > > -> New -> Window to open up another window with the same
> > > -> cookie/sessionID
> > > and the user could actually go to a different module and do
> > MORE work
> > > at the same time. This would allow, for example a large
> query to be
> > > performing in one module and they could go do some work in another
> > > module. My method of a flag would prevent this type of
> > > multiple-module capability.
> > The solution,
> > > ofcourse is to allow one flag per module, thus only one
> > transaction per
> > > module could be performed, which is what I intend to
> > implement to at least
> > > keep the user experience at a satisfactory level while
> > preventing tons of
> > > form submissions from inundating the server.
> > >
> > > So anyone had this experience and resolve it in some manner?
> > >
> > > Thanks.
> > >
> > > ==================================================================
> > > =========
> > > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> > > JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body:
> > > "set JSP-INTEREST DIGEST". Some relevant FAQs on
> JSP/Servlets can be
>
> > > found at:
> > >
> > > http://java.sun.com/products/jsp/faq.html
> > > http://www.esperanto.org.nz/jsp/jspfaq.html
> > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
> > > ----------------------DISCLAIMER-----------------------
> > > The information contained in this e-mail and any files transmitted
> > > with it are confidential and intended for the addressee
> > only. No other
> > > person is authorised to copy, forward, disclose, distribute
> > or retain
> > > this email in any form. If you have received this e-mail in error
> > > please notify the originator or send an e-mail to
> > > [EMAIL PROTECTED] This e-mail and any associated
> > > attachments have been scanned for viruses prior to
> dispatch, however
>
> > > Emap Performance and its subsidiary companies accept no liability
> > > for any losses resulting from infected e-mail transmissions.
> > >
> > > Please note any views expressed may be those of the
> > originator and do
> > > not necessarily reflect those of this organisation.
> > > --------------------------------------------------------
> > >
> > > ==================================================================
> > > =========
> > > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> > > JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body:
> > > "set JSP-INTEREST DIGEST". Some relevant FAQs on
> JSP/Servlets can be
>
> > > found at:
> > >
> > > http://java.sun.com/products/jsp/faq.html
> > > http://www.esperanto.org.nz/jsp/jspfaq.html
> > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
> > >
> >
> > ==============================================================
> > =============
> > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> > JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with
> > body: "set
> > JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets
> can be found
> > at:
> >
> > http://java.sun.com/products/jsp/faq.html
> > http://www.esperanto.org.nz/jsp/jspfaq.html
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
> > ----------------------DISCLAIMER-----------------------
> > The information contained in this e-mail and any files transmitted
> > with it are confidential and intended for the addressee
> only. No other
>
> > person is authorised to copy, forward, disclose, distribute
> or retain
> > this email in any form. If you have received this e-mail in
> > error please notify the originator or send an e-mail to
> > [EMAIL PROTECTED] This e-mail and any
> > associated attachments have been scanned for viruses
> > prior to dispatch, however Emap Performance and its
> > subsidiary companies accept no liability for any losses
> > resulting from infected e-mail transmissions.
> >
> > Please note any views expressed may be those of the
> originator and do
> > not necessarily reflect those of this organisation.
> > --------------------------------------------------------
> >
> > ==============================================================
> > =============
> > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> > JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body:
> > "set JSP-INTEREST DIGEST".
> > Some relevant FAQs on JSP/Servlets can be found at:
> >
> > http://java.sun.com/products/jsp/faq.html
> > http://www.esperanto.org.nz/jsp/jspfaq.html
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
> >
>
> ==============================================================
> ==========
> ===
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with
> body: "set
> JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found
> at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
> ==============================================================
> =============
> To unsubscribe: mailto [EMAIL PROTECTED] with body:
> "signoff JSP-INTEREST".
> For digest: mailto [EMAIL PROTECTED] with body: "set
> JSP-INTEREST DIGEST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
