Recently I am working on a project which using ajax to call java servlet, and the request takes more than 10 sec to get the response, so I need to make sure during this time user won't be able to submit the form again, and my current approach is detect submit button click event and disable submit button, once success or error function is triggered in ajax, enable the button again, but this is not a good approach.
---- Edit ----
Sorry, I wasn't explain clearly, what I mean is this can stop non technical background user, but if any one intend to attack the site or whatever reason,
they can simply modify html code to enable the button, and do another submit,
Before I tried another way which set a cookie interval after form submit, and check the cookie when request finish, but just wondering whether there is any other way to do this, this question is purely for learning purpose.
Sorry for my English:)
I dont see anything wrong with disabling the button, that is what I frequently use, because this not only provides an indication that the system acknowledged your click but also prevent the user from clicking again.
If for some reason you dont like that you can disable the underlying method call something like this:
var isSubmitting = false;
function handleClick(){
if (!isSubmitting)
{
isSubmitting = true;
$.ajax(
"http://yourservice/submit" {
data: {someData:123},
contentType: 'application/json',
type: 'POST',
success: function(){
isSubmitting = false;
},
});
}
}
About your edit, the cookie sounds like a good approach, basically you need something that the server is going to pass to the client, and then check on submit. once that has been authorized the server will prevent processing of further requests with the same parameter.
But bear in mind that a malicious user would spawn thousands of requests to get cookies and then perform all the submissions anyway, so it is not really a defence against attackers, for that you would have to implement some form of throttling.
So in the end if you just want to prevent accidental submissions the button hide will suffice.
Something I have done and has been successful is a combination of what you described and preventing the function called by the button to execute twice. I do this by keeping a variable that gets set to true with the first request, then on subsequent request I check for it, if it's true, I don't do anything. Something like this:
var isRequestAlive = false;
var submit = function(){
if(!isRequestAlive){
isRequestAlive = true;
doAjaxStuff("", function(){
isRequestAlive = false;
})
}
}
Related
I would like to implement a page that be displayed to the user whilst a system command is run. As soon as the command completes the user should be routed to another page.
What are some strategies to implement this?
(A solution without javascript would be ideal)
It can definitely be done. You want to look at Asynchronous programming with HTTP in the documentation, it explains how to do this in a non-blocking way. You will need a little bit of javascript for the redirecting part though.
And I don't know what you mean with "system command" but you probably want to create a job for it, so you can trigger it with a request. You can then poll it until it's finished and then redirect the user. But really the documentation does an infinitely better job at explaining it then I'm doing now.
Here's an example of a controller action where I assume your system command returns some kind of String output for the user. When the Job is completed it will sent a response to the user, thus triggering the success handler in the javascript example.
public static void executeSystemCommand(String input) {
Promise<String> outputPromise = new SystemCommandJob(input).now();
String output = await(outputPromise);
renderText(output);
}
Basically if you're using jQuery's $.ajax you can use the complete event to poll the data (just do the request again if it didn't succeed within the timeout time) and use the success/done event to redirect the user when the application responds to indicate that the "system command" is done running.
Example of a function you could use:
function poll(){
$.ajax({
url: "/systemcommand",
success: function(data){
// redirect to next page here
document.location.href = '/output'
},
complete: poll,
timeout: 20000
});
};
There is also a great example on long polling in javascript on StackOverflow.
This question is related to another question of mine: How to know if a user log out of Facebook, FB.Event.Subscribe not work
In that question, I tried to get a call back event when the users log out of Facebook. But since it has no appropriate answer yet, I must try another way. I try polling to get the login status of a user by javascript, like this:
function checkLogin()
{
alert("in");
FB.getLoginStatus(function(response) {
if (response.status == "connected") {
// logged in and connected user, someone you know
alert("ok - 5 seconds has passed");
} else {
// no user session available, someone you dont know
alert("not ok");
}
});
t=checkLogin("timedCount()",5000);
}
The problem with this is that: the function only returns the correct result the first time it gets called. After that, it seems the result is cached, and I continously received "connected" in response, although the user silently logged out by another tab in browser.
This is not good, because at that time Facebook pop out a dialog which ask the user to login. But if the user cancel it, he still can work with my application (caused his session with my application server is not expired yet!).
In the document, FB dev says that:
When you invoke FB.getLoginStatus, an HTTP request may be made to
www.facebook.com to check the current status of the user. However, if
FB.getLoginStatus has already been called during this browser session,
and a session has been persisted within a cookie, an HTTP request to
facebook.com may not be needed
So I think this effect caused by the cached. I wonder why Facebook do it that way.
Does anyone know a work around for this issue?
Thanks for any help,
Hoang Long
It took me a long time enough, eventually, until one of my co-workers solved the problem.
The solution is that we need to call FB.init() again, with cookie:false before calling getLoginStatus. This will remove the cookie and get new information.
FB.init({
appId:'${appId}',
cookie: false,
status: true,
xfbml: true
});
FB.getLoginStatus(function (response) {
if (response.session) {
alert("here");
}
});
I have a web page that has a function that will send an initial request to a web service.
After some predefined time, the user can send a second request.
After the user sends the first request, I want the web page to countdown when the user may send the second request.
After the countdown, I want a DB field to be updated automatically, indicating that the appropriate time has passed.
When the time has passed and the DB updated, I'd like the webpage updated to show a button that would allow the user to send the second request.
After the initial request, call a JavaScript user-defined function "countdown()" using the in-built JavaScript function "setTimeout("countdown()", 4000)", where the number "4000" resembles the number of micro-seconds that need to be passed to fire the function mentioned in the first parameter.
In the "countdown()" function, write the logic for the AJAX call, where you will be updating the database that the desired time of 4 seconds (for example) has passed & now the user can send the second request.
Also in the same AJAX call, you can print out some word (let the word be "yes" for example), which you can catch / fetch it in the "countdown()" function definition, using the "responseText" keyword of JavaScript's "XMLHttpRequestObject", in a dummy variable "flag".
Now you can write something like the following in the "countdown()" function definition:-
function countdown() {
document.getElementById("btn_second_req").style.display = 'none';
var flag = '';
// all code to prepare for AJAX call
// AJAX called, return also fetched in a variable "flag".
if (XMLHttpRequestObject.readyState == 4 && XMLHttpRequestObject.status == 200) {
flag = XMLHttpRequestObject.responseText;
}
if (flag == 'yes') {
document.getElementById("btn_second_req").style.display = 'block';
}
}
So by default, the second request firing HTML button is hidden from the very first time, & only activated when the "flag" variable condition is satisfied.
Also since the details of the first call of any user is being kept in the DB, so in the second call, you need to check with server validation that there exists details for the first call, otherwise the second request call will not be entertained.
These type of logic can easily be implemented using any JavaScript framework library (like jQuery or Prototype) or by plain JavaScript only.
Hope it helps.
Yes, it can be done. Here is how I would do it, which is almost as you describe it.
1- The web page sent the request to the service. The service compute the time until the next request can be executed, store it in a db field/in session (depending how your service work), and send it back to the client, plus whatever it is your service send back.
2- You create a timer with the setTimeout function of javascript (or an equivalent if you use a javascript library) http://www.w3schools.com/js/js_timing.asp .
3- When the timer execute, you send a request to the webservice to ask if its ok to start the second request. The server check the time in the db field. If it is past "next request time", the server respond positive, else it return the remaining time, and the client then create a new timer.
4- You send your new request. The server check again if its "next request time" (in case someone smart hack the javascript, or if their is a bug on the client). If it is time, it execute the second request.
The only difference is that with the way I described, everything on the server execute as the result of a client action, so you don't have to mess with thread/cron job to auto update your db field.
Good luck!
I had the following:
Link 1
but I noticed that the javascript function CreatePageView() did not get executed all the time and was creating a race situation. Sometimes the javascript would get executed, others times the redirect was happening first.
So I wanted to control the order of events and thought to invoke the servlet within my javascript function.
function CreatePageView()
{
//Execute javascript function here
//Invoke servlet here
document.forms[0].action = "/servlet/MyServlet";
document.forms[0].submit();
}
When I invoke my servlet, my session gets destroyed and I get redirected to the login page. Can anyone explain why this is happening? Or perhaps suggest an alternate method of invoking the servlet without killing the session? Thanks in advance.
This sounds much like as if that JavaScript is firing an asynchronous request. Otherwise the problem doesn't make any sense. The link's action will in any way only be executed when the JavaScript function has returned. But when you're firing an asynchronous/ajaxical request in the JS function, then indeed a race condition may occur. It namely doesn't execute in sync. It executes "in the background".
You need to ensure that the link is only invoked when the asynchronous request is finished. Assuming that you're doing it in "plain vanilla" JS by XMLHttpRequest instead of a convenient Ajaxical JS library like jQuery, then you need to do the job in the onreadystatechange.
Change the link as follows:
<a href="/servlets/MyServlet" onclick="return createPageView(this)">
(note that the javascript: pseudoprotocol is unnecessary and that JS functions usually start with lowercase)
And fix your JS function as follows (not MSIE compatible, fix that yourself)
function createPageView(link) {
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if (xhr.readyState == 4) {
window.location = link.href; // See?
}
}
xhr.open('GET', 'http://example.com', true);
xhr.send(null);
return false; // Block link's default action.
}
As to the question why the session get destroyed, it will be "destroyed" when the request headers doesn't contain the proper session cookie, or when you call session.invalidate() in server side, or when the request is been fired on a different domain/context. You're the only one who can investigate which one is the culprit.
I need to show a progress bar to the user who requests a file to download. I am using J2EE application to generate the file. User will submit the form data to get the file. The server takes all the submitted data manipulates, generates and sends a PDF file back to Client.
So I want to show a progress bar to the user till the file comes to the Client side.
Is there any way to do this ?
If I understand you well, you want to show a progress bar until your server is ready to send a file, not to show the progress of the file beeing downloaded.
If that is true, you're dealing with a tough excercise. A reliable progressbar needs to know (pretty exact) what you're doing and how long it will take. In your case, there are lots of unreliable factors (one of them, maybe the biggest, is the web itself).
So most developers use some kind of an "endless" animation to display "work in progress".
update
Based on your comment, the easiest way to display a "work in progress" animation would look like
$.ajax({
url: "/myscripts/myserverscript",
type: "POST",
data: {
foo: "bar"
},
dataType: "text",
beforeSend: function(xhr){
// display a progress animation
},
complete: function(xhr, status){
// hide the animation
}
...
});
In the case of a single request. You may also setup a global ajax event handler for both (.ajaxStart() and .ajaxStop()) to setup the show/hide functionallity.
References: .ajax(), .ajaxStart(), .ajaxStop()
progress bar for server side file generation:
We assume that the server needs many seconds to generate the file. This event is triggered by the original request, a blocking operation. When this finishes the file will have been generated and it'll be dispatched back to the client.
At the same time you want, via other requests (ajax), to be calling the server and getting a percentage back for the file which is currently being generated for the particular user.
The glue parts here are:
when the original request is generating the file it needs to store the progress in frequent intervals (i.e every 10%). Storing this data in the http session will work OK.
the other requests (ajax) simply need to be able to pull this information out of the http session
synchronizing (serializing access) on the http session, something that some web apps commonly do, is out of the question, since the other requests (ajax) would simply block until the original request finished
on the client side it's all html+javascript to provide the interaction you need (animated progress bar). Even if the intervals are very rough (jumping from 10% to 20% to 30%) you can animate the bar with jQuery. I've done it once in the past and it looks great.
progress bar for file download:
it's best to leave this to the browser's native dialog.
In Java you just wrap a javax.swing.ProgressMonitorInputStream around the input stream, but be aware that unless the server is sending in chunked streaming mode the display won't really mean anything, as the entire response will have been read into memory before the first byte is delivered to Java.
Using XMLHttpRequest you can download file and show progress.
showProgressBar();
var xhr = new XMLHttpRequest();
xhr.open("GET", 'https://upload.wikimedia.org/wikipedia/commons/d/dd/Big_%26_Small_Pumkins.JPG', true);
xhr.responseType = "blob";
xhr.onprogress = function (e) {
console.log(e.loaded / e.total * 100);//shows downloaded percentage
setProgressBarPercentage(e.loaded / e.total * 100);
}
xhr.onload = function () {
hideProgressBar();
var urlCreator = window.URL || window.webkitURL;
var url = urlCreator.createObjectURL(this.response);
var link = document.createElement('a');
link.setAttribute('href', url);
link.setAttribute('download', 'FILENAME');
link.click();
}
xhr.send();