I have a large web page (classic ASP) with lots of information required from the user, so lots of inputs. The user's behavior is that he will fill in the information over time, analyze it and other time consuming processes before submitting. The problem is that even though the session timeout is set to a reasonable 30 minutes, often i get complaints that when submitting, the user gets the timeout message and loses all his work, all he filled in before. I thought it would be elegant to check on the submit event if the session is abandoned, in which case to have a login form appear. By using Ajax synchronous, for the session check, and for the login itself, the state of the web page will remain unaltered, allowing the user to continue with the submit after the session has been restored.
However, I've been reading about the perils of synchronous, and how it is recommended to avoid when possible. For me it seems that this is one of those cases when synchronous is required, but i didn't find anyone that has done this before.
I am looking for advice on whether this is a good course of action, using Ajax synchronous for a session restore.
Thank you.
There is no need to do a synchronous request here. You can cancel the form submission (return false or event.preventDefault() from the submit handler), start the asynchronous XMLHttpRequest to do the check, then in the AJAX response handler either display a message or restart the form submission (form.submit()) as appropriate.
I'd suggest 30 minutes is probably not a reasonable session timeout if it is causing these problems. A longer timeout, and/or having the form ping the server back to keep the session alive, might be a more convenient approach for users.
Related
I'm working on an application stack that has a rather particular architecture. The forms component is loaded on a view, and when the action is submitted, an async call using sidekiq is performed. This calls an endpoint that validates the form data, but none of this is returned back to the server and after this process is fired, there is a redirect to another page.
We want to add cookies to write the status of this call sidekiq did. This is not possible to do on the controller as the controller when it is rendering the destination page has no knowledge of this event that occurred. The possibility of writing this cookie on the async callback is tempting but this is not done on the controller (The controller loads a class that contains a module with this functionality)
Question: Is it possible to write cookies in places not in the controller, such as classes or models? I'm assuming no, but I figured it might be an interesting question.
It's not possible. Writing a cookie is a part of HTTP response, so you need to be in the request-response cycle, i.e. in the controller.
What you could do (and I did that more than once) is to have some kind of record in the database, storing a status of a background job, and from the page you redirected to periodically poll some endpoint with AJAX (or establish a Websocket connection) to check if the job has finished and with what status. Then you'll be able to set the cookie.
There are some servlets which I call from ajax to check user availability and some other work. An ajax request can be send only if user is login.
But the problem is, user can hit server through ajax call mass number of times in a second using javascript injections. It can make server down.
There is one possibility to control it;
If number of hits from same IP in a
second(or some period) crosses the
maximum limit then I can invalidate
the session.
But some of my colleagues are not in favor of limiting the user. Is there any other way to safe my server from ajax bomb.
You have a few options:
you can throttle ajax requests, slowing them a little when they hit a limit, as some sites do.
rate limit (completely block) the ajax request after X requests, as Twitter does with its API
choose another option, like WebSockets.
These can be either server-sided or client-sided, server-sided being the obvious choice for security.
But the problem is, user can hit server through ajax call mass number of times in a second using javascript injections. It can make server down.
Javascript injection is the least of your problems if you're concerned with your server staying alive. Raw HTTP DDoS attacks are a much bigger problem than a few ajax requests. The main thing Javascript injection should stick right in your mind is to do with security, not server uptime.
i had the same problem with some web app i have developed,
the solution i came up with was to check the referer on the server-side,
and only allow calls from the server (127.0.0.1).
I have writen searching in my site and now I am trying to make it search every time I start printing. So now I am sending many requests which contains different text to search for using AJAX one by one and every next reqest has to wait, before previous one is finished. Apperently I dont need old requests to be answered, but I need the only one response for the last request.
How can I kill the queue of not actual requests in Django?
Does anybody know the answer?
On the server side, it's probably too late to cancel requests, but you can ignore the responses on the client side. I would suggest aborting a pending AJAX request before sending a new one.
Here is how:
Abort Ajax requests using jQuery
An easier way to do this could be by waiting a bit before sending your request to the server. After each input, set up a timer that stops the previous (setTimout) and only send the request if the timeout is met.
If a request was already performed and has not returned you can still kill it as suggested in another answer.
I'm not aware of how to stop other requests using django -- hope that it's not even possible, it would be a security thread if requests could be killed by others.
I have made webpage that uses Ajax to update some values without reloading the page. I am using an XMLHttpRequest object to send a POST request, and I assign a callback function that gets called when the response arrives, and it works just fine.
But... how in the world does the browser know that some data coming from some ip:port should be sent to this particular callback function? I mean, in a worst case scenario, if I have Firefox and IE making some POST requests at roughly the same time from the same server, and even making subsequent POST requests before the responses arrive to the previous ones, how does the data coming in gets routed to the right callback functions ??
Each HTTP request made is on a seperate TCP connection. The browser simply waits for data to come back on that connection then invokes your callback function.
At a lower level, the TCP implementation on your OS will keep track of which packets belong to each socket (i.e. connection) by using a different "source port" for each one. There will be some lookup table mapping source ports to open sockets.
It is worth noting that the number of simultaneous connections a browser makes to any one server is limited (typically to 2). This was sensible back in the old days when pages reloaded to send and recieve data, but in these enlightened days of AJAX it is a real nuisance. See the page for an interesting discussion of the problem.
Each request has its own connection. Means that if you have single connection, of course you will have single response, and this response will be in your callback.
The general idea is that your browser opens a new connection entirely, makes a request to the server and waits for a response. This is all in one connection which is managed by the browser via a JavaScript API. The connection is not severed and then picked up again when the browser pushes something down, so the browser, having originated the request, knows what to do when the request finishes.
What truly makes things Asynchronous, is that these connections can happen separately in the background, which allows multiple requests to go out and return, while waiting for responses. This gives you the nice AJAX effect that appears to be the server returning something at a later time.
Is there any difference in performance ( speed wise ) between a synchronous request and and asynchronous request?
What all are the reasons for using an asynchronous request??
You should mostly always use an asynchronous Ajax Request, in fact I know only about one place where a synchronous Ajax Request should be used which is if you're in an Ajax Request embedding a new JavaScript file on the client and then referencing types and/or objects from that JavaScript file in the return from the original Ajax Request. Then the fetching of this new JS file should (or can sanely) be included through using a synchronous Ajax Request...
Other then that you should always use asynchronous Ajax Requests. The most important reason is that a synchronous Ajax Request makes the UI (browser) unresponsive...
#Thomas Hansen answer is right but I found a clear explanation with benefits of Asynchronous.
Synchronous is simple, but wait for the server response, thus block the execution of the caller for a period and slower than asynchronous while processing the request.
Asynchronous is required setting, do not wait after submitting the request and immediately return control to the caller, thus faster than Synchronous.
I am coming here when I have to use upload control which has both functionalities in the question and looking the pros and cons of this functionality.
I got the another link which explained with a real example. (the link is the specific tool, so understand the logic)
The major difference is the response time from our servers. At the time of upload, synchronous will validate file and create the passcode in real-time. Asynchronous will send the file to our server's queue and deliver notification via email once it is processed.
Synchronous is not ideal for multiple, large CSV file since you will need to wait until the file is processed by the server to submit another request. On large files, this also may cause your browsers to return with timeout errors due to the server being too busy. If you have multiple files, asynchronous will allow you to submit multiple files to the server queue to be processed with a email receipt once completed.
https://www.aspsnippets.com/Articles/Difference-between-Synchronous-Sync-and-Asynchronous-Async-Request-Call-in-AJAX.aspx
there can be serious performance implications caused when it come to highly database intensive applications .. although it's very unlikely to happen .. and sending many Synchronous ajax calls can create a backlog .. so if the application database intensive and sending so many request at once it is better to make it asynchronous.
when its set to asynch the browser will fail all unresponsive request and continue with new once..