I'm working with a 3rd-party payment service that sends my user back to my site after doing a payment on their site. It sends the user back with javascript (setTimeout and location='my_site.com?data'), but there's also a button the user can click if it takes too long. The double request happens when the browser is already loading my site because of the javascript, and the user clicks the button.
Can I prevent the request is handled twice? Or should I simply handle it twice?
Right now, I show a "request is already handled" when the same request is handled twice, but because the two requests happen near simultaneously, the user never sees the page that says the request was correctly handled.
Ideally the button should be disabled at your service provider, but otherwise you'd have to manage it gracefully on your side...
In this case you want your user to get the correct feedback and from what you've said you are aware that they currently lose the response to the first request.
So what you probably want to do is for any subsequent request (possibly only within a certain time frame) to check if the event has been handled already. If it has been handled already you may want to check that the handling is consistent (ie that the data is the same both times and deal appropriately if the data is in fact different).
If its all the same you can display the "handled correctly" page whether it is the first or second or tenth time they went to the page.
Other techniques to handle this may include making sure that your landing page returns faster. Presumably the problem is that a reasonable amount of work is being done on your side whcih is causing them to give up and go for the click as well. If you can reduce this time to display content then that may solve your problem in a slightly better way. This might involve something like returing a small page that has your site branding and says "please wait while we process your order" or whatever. This then puts the control in your hand and allows you to more intelligently deal with the double click scenario at the beginning.
Exact solution will depend on your exact situation though.
Just disable submit button before calling form.submit():
document.getElementById("submit").disabled=true;
Related
I am looking to build an in-house debugging system so we can see how users react to certain things.
What would be the best way to communicate all mouse clicks, moves, etc. back to the server?
One way I've thought of is to run a bind on body for everything and then just add it to an array which is sent at page unload, but I figured this could seriously kill a browser if the user has decided to click everything in sight or has sat there in work for 4 hours just moving his mouse on the page.
Ideally I want to avoid web sockets.
I'm sure this has been done before so I'd love to know how it's been done.
Thanks
For those of you wondering, I used the answer found here (How do you log all events fired by an element in jQuery?)
as a wrapper, with a combination of #hallleron's approach - storing the values in a string separated by | firing off AJAX queries every 3.5 seconds, then setting the array back to null. On page unload, the AJAX query fires one final time.
I'm also considering making the unload script dynamically create an iFrame with (again) a dynamically generated form and contents which auto posts the contents, just in case the AJAX hangs for whatever reason.
All array strings use their own CSRF token and have a randomly generated ID for the client side which is then hashed on the server side and is used to check if that has already been sent, just to stop any possible double AJAX requests.
On the server side, it is stored using ARCHIVE Engine Type and also INSERT DELAYED Insert method.
Eventually I'll probably move the logging system to its own EC2/RDS group.
The reasoning behind all this is to be able to see the most popular features of the website, who is clicking where (say if there's 2 home buttons, which one is more popular, etc.)
Hope this helps anyone else stuck in this predicament.
End users are often told not to hit the submit button twice, allowing the transaction to complete; and, there are different techniques used to address this situation.
Recently though, someone asked me, "what do you do to handle the situation of a user doing a page refresh after doing a submit", the implication being that this will cause a double submit or other problem.
Can you let me know if this is a real problem that needs to be handled ... what the situation is and how to best resolve it, if at all.
The best way to resolve this is using the Post/Redirect/Get pattern.
Yes, this is a real problem unless you handle on your side. In practice on most browsers when the user hits refresh the data is resubmitted and if you on the server side do not check for this it would result in you taking the same action twice (e.g. charging a credit card twice, duplicate forum post et.c.).
The way to handle this is to check whether the user has previously done a post. For example, if you are building a forum you would send a hidden variable with a unique ID with the post. As you parse the posted data you save this unique ID into your database. If you ever encounter a post with a unique ID that has already been saved you know that you are looking at a "refresh" on the client side and you simply disregard the post.
Hope this helps!
If your users are so inclined to do a page refresh, it sounds like you have a service taking way too long to respond. Disable the submit button on submit, and show some kind of loading indicator until the response comes back.
Alternatively, respond immediately on the server and queue the action for later. Linode, for example, queues server behavior, rather than running immediately on "request to resize partition". You can generalize this approach for other behavior, and even show things like progress indicators and the like with ajax.
Yes, it can be a problem (and actually is a problem in a lot of websites).
But I think this is more of a server side related question than Javascript.
Best practice is to use Post/Redirect/Get pattern (since you are asking specific about refresh after submit).
Yes it is a real problem but I believe this is typically handled by the browser. Chrome for instance will notify you on page refresh if there will be data posted to the server as a result, and give you the option of continuing or aborting.
EDIT:
Actually... come to think of it I did have to deal with this at work. What I ended up doing was creating a shadow box over the page untill the process was complete to
give visual feedback that the process was working and
Prevent any other user actions.
"what do you do to handle the situation of a user doing a page refresh after doing a submit"
You should redirect to the page after a form is succesfully submitted.
This would prevent that the user submits the data again and prevents that anoying alert of the browser saying the data will be submitted again.
I have an application that send very big quantity of requests to the server (they appears after the page is loaded, and made from flash app)
This happens so often that status line go mad (displaying: Transferring data text every few seconds), and it's really annoying.
I that possible to handle all events on the page, and don't allow them to change status line? Or set it to empty string, if it's impossible to disable?
In many UAs the user can disable the "feature" of changing the status line with JavaScript so the short answer to your question is:
No, at least not reliable.
A not reliable semi solution could be that you launch your webapp in a new window without a status bar. But again, not reliable as users can override that or have new windows open as tabs etc.
Possibly OT: personally I think the user has the right to know when her/his UA is sending and/or receiving data. It´s about integrity, privacy and all that stuff.
Just try to embrace the fact that the end user (the actual owner of the UA) is in control (and should be).
I know a few sites (such as my bank and my school) that kill a session after their has been idle for a set amount of time. It is my understanding that session activity is determined by users following links or at the very least from some kind of active interaction, like updating a form via ajax. Basically the server gets a request to do something during the session and goes ahead and extends the session time another 15 minutes.
But on some occasions I have lost major amounts of time and info while filling out a text box or reading some long set of instructions along the way.
So why not have an ajax script that listens for keyboard activity and mouse movement and lets the server know that the user is still there and active, even if they aren't clicking a submit button or following a link?
I was wondering if anyone knew of respectable sites that already do this, or if I was overlooking some major security hazard with this idea.
The only thing I can imagine would be risky are the random acts of cats, vibrating electronics nearby, or a hyper child.
But in all of the above, the user is most likely at home and -- unless they are trying to get exploited -- have probably minimized the window and thus these things are very unlikely to trigger as an event.
Does anybody see any other major risks?
Typical AJAX sites are making posts back to the server anyway. These events are renewing the users session already.
If you put these events on keyboard or mouse clicks, how many times are you going to be posting to the server? If I am typing in a form field like I am now, that means you could potentially have a ping to the server for each letter I type; not a very efficient solution. On the other end, what if your user is just sitting their reading or using an external text editor to type their text into and will copy it into your form later.
I think the more typical solution to provide a friendly UI so that long posts do not get dropped because of a session expiration is to use an auto-save feature. Google Docs does this. Every few seconds/minutes, they post the contents of the editor back to the server without the user actually clicking save/submit. The other option is to inform the user that their session is about to expire (could be done with a javascript timeout). Provide a link to ping the server to renew the session.
Your solution lends itself to the same problem: you are relying on user behavior. In the first case, navigating between pages and in the second, mouse clicks.
I used to work for a company that did a lot of online contests where users would have to enter essay content as well as shorter blocks of data; we used to modify the session time out "session.setMaxInactiveInterval()" for the user's session when they hit the "long-winded" page so that they would have more time to edit, and then we would set it back to normal after the submit.
Later at that company and a couple others I worked at I proposed a solution similar to what you are describing, but for various reasons it was never accepted. It was never considered a bad idea, just not one we chose. Basically it was going to be an ajax call on a timer so that just before the session timed out, it would fire off a light-weight ajax "ping" and keep the session alive as long as that page was open. I have never had the chance to implement it in the "real world" so perhaps there are negatives that I have not thought of.
Good luck.
In my web application, I'm providing a link, clicking on which goes to another page, shows some data,popups a page and goes back using javascript back() function.
It was working fine but it fails in certain cases. For example, this link appears after a form submission also. When the back() function is called here, the Webpage Expired message is shown because it was a POST operation.
How can I go back to the previous page using javascript in this situation?
Please provide your inputs...
You can't do anything about page expiration from JavaScript - that's how the browser opts to protect the user from re-submitting the form accidentally.
You could use the POST/Redirect/GET approach, depending on how your application works, to ensure users always land on a GET after submitting their form, so you always have a valid state to go back to.
To be honest, 99% of the time using the back() functionality in JavaScript is an indication something's wrong in the underlying approach. It's just too fraught with problems to be workable, as you're seeing here. You might get further if you start a new question to describe what you're trying to accomplish. There's a lot of really smart people around here who can all put their heads together and help you come up with something.
Can you explain why you need to navigate to the previous page using client-side script? I'm assuming it's because the user may be arriving at this page from various other pages and you want to direct them back to the page they came from. You could always store the user's previous page URL in a session or cache object and direct them back to that URL in server-side code. Or, if you know where they will always be coming from, direct them back to a static URL. I may be able to offer more assistance if you offer more details.