RE: When user hits STOP..any way to trap that and terminate an ongoin g request..
You make it sound so simple..yet its not quite that easy. I do keep the state of the user on the server, of course. But that still wont prevent the user from stopping a query that could potentially take a long time, then submitting again, while the original one is still going on. I would love for you to explain to me what you mean, and how it works, because frankly your reply was a little vague for me to come up with a resolution out of. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Magnus Rydin Sent: Wednesday, August 15, 2001 11:23 PM To: Orion-Interest Subject: SV: When user hits STOP..any way to trap that and terminate an ongoin g request.. Just keep the users state server side and you're home. WR -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]För Aaron Tavistock Skickat: den 14 augusti 2001 02:50 Till: Orion-Interest Ämne: RE: When user hits STOP..any way to trap that and terminate an ongoin g request.. This is a fairly classic web issue and unfortunately there is simply no way to tell if the client has hit the stop button. No matter what happens your going to be stuck running that long query no way out... But on the resubmit issue and using the session to flag a large transaction, I would worry about this alot. For one, what if the user really didn't want that massive query, now they are being penalized until their query is completed. Personally I think the Jakarta Struts folks came up with a fairly decent way of curbing reposters. Basically they add a hidden field to every form with a unique token, that token is recorded when the form is submitted, and thereafter the same form will not be accepted. So the user can't just hit back and then OK, but they can go through the normal route to search again. -Original Message- From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] Sent: Monday, August 13, 2001 1:23 PM To: Orion-Interest Subject: When user hits STOP..any way to trap that and terminate an ongoin g request.. 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
RE: When user hits STOP..any way to trap that and terminate an ongoin g request..
Title: Ayuda Kevin, tough I value the trouble you've been taking to hack around this orion bug, it is a BUG, and therefore should be corrected. AFAIK, this is the only exploit that orion exposes, and it is VERY problematic. DoS attacks are very easy to perform... just pick any "heavy" page on a site, open a socket, send a very short HTTP header, then drop the connection. Do it quickly and orion will choke up. Most IDS and Firewalls can't block this kind of attack with their default settings, and when programmed to block, they cannot be efficient. -Original Message-From: Duffey, Kevin [mailto:[EMAIL PROTECTED]]Sent: Lunes, 13 de Agosto de 2001 16:23To: Orion-InterestSubject: When user hits STOP..any way to trap that and terminate an ongoin g request.. 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.
RE: When user hits STOP..any way to trap that and terminate an ongoin g request..
This is a fairly classic web issue and unfortunately there is simply no way to tell if the client has hit the stop button. No matter what happens your going to be stuck running that long query no way out... But on the resubmit issue and using the session to flag a large transaction, I would worry about this alot. For one, what if the user really didn't want that massive query, now they are being penalized until their query is completed. Personally I think the Jakarta Struts folks came up with a fairly decent way of curbing reposters. Basically they add a hidden field to every form with a unique token, that token is recorded when the form is submitted, and thereafter the same form will not be accepted. So the user can't just hit back and then OK, but they can go through the normal route to search again. -Original Message- From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] Sent: Monday, August 13, 2001 1:23 PM To: Orion-Interest Subject: When user hits STOP..any way to trap that and terminate an ongoin g request.. 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.
