I have a question.
I send a Get request by Ajax every second and expect to get some response from the server.
In the case and my application crashes and I continue to send Get request every second, I don't get any response until receiving the server's timeout error (an error code 502.) .
If somebody knows how I can handle this moment between sending the get requests every second and until receiving error code 502.
Thanks
If the server is down, whatever you are using for the ajax call should have errored out... in which case you should handle it with a call back or a catch block. There, you should handle what you will do on the frontend based on the response.
As far as not sending out more requests, there really is no way to know for sure. For all your code knows, the server is particularly slow at that moment.
Imagine situation, I've ajax.php file that displays specific information based on ajax request.
How can I block all requests going to ajax.php file except coming via ajax?
I'm looking for something like this in php:
if ($ajax) {
//Do soemthing
}
Will this guarantee that malicious user won't be able to see what ajax.php has to display? Since ajax has same origin policy, request must originate from the same domain, so in theory nobody will be able to call my ajax.php?
There is no way to reliably tell whether a request is an Ajax request or not, ever. Any client side information (like the referer) can be spoofed and you can not trust any of it.
You secure Ajax requests like any other request - usually through a session-based login system that checks whether the requesting client is logged in, and what they are allowed to see.
Other answers already mentioned it: there's no reliable way to determine if a script was called via an AJAX request. But I use this code to detect AJAX request:
define('IS_AJAX', isset($_SERVER['HTTP_X_REQUESTED_WITH']) && $_SERVER['HTTP_X_REQUESTED_WITH'] === 'XMLHttpRequest');
Keep in mind that it can be spoofed, so don't depend on it.
What am doing to secure our ajax requests - Whenever any user logins at that time generate a token for the user e.g get the micro time and then convert into some hash, then attach this token with that user.
I'm making ajax request to server on another domain but I don't actially need its response, just to know that it got my request.
When everything is ok, in Chrome Developer Tools (Header status) it says «canceled» and console writes «XMLHttpRequest cannot load» but server gets my requests.
When server is down then header status is not a number but just «failed».
Trying to catch this critical difference on JS I get XHR status 0 in both cases.
I'm making ajax request to server on another domain
You can't make an ajax request to a different domain, due to same-origin policy. You want to look at JSONP, which essentially writes out a <script> tag for a remote URL.
What is JSONP all about?
Detecting success/error with JSONP calls is tricky, it doesn't work like typical ajax calls at all. Ideally you want the remote server to call a callback function on your page, as the above link describes.
If you don't control the other domain, you can attempt to detect errors by using a timeout. Here is a post discussing the jQuery timeout argument for this, though you could certainly implement your own timeout with raw javascript as well.
I use the jQuery ajax functions to access a web service, but the server, instead of returning a response with a status code describing a problem, the request is redirected to a page with a 200 header, describing the problem. I can't make any changes to this, so I need to solve it on the client somehow.
Example:
A request goes to some URL which is not found, so I receive a 302 Redirect to another location. A new request is sent, and I receive a 200 OK, thus preventing the error callback to fire.
Is there some way I can prevent the ajax request to follow redirects and instead invoke a callback, preferably the error method. Alternatively, is it possible to detect if a redirect has happened in the client?
I find your question interesting, but the problem in whole seems me more a misunderstanding. At least I'll try to explain my understanding of the problem.
The silent (transparent) redirection is the part of XMLHttpRequest specification (see here especially the words "... transparently follow the redirect ..."). The standard mention only that the user agent (the web browser) can prevent or notify of certain kinds of automatic redirections, but it's not a part of XMLHttpRequest. It's the part of HTTP client configuration (OS configuration) or the web browser configuration. So jQuery.ajax can't have any option where you can prevent redirection.
You can see that HTTP redirection is the part of HTTP protocol and not a part of XMLHttpRequest. So it's on the another level of abstraction or the network stack. For example the data from the XMLHttpRequest can be retrieved from the HTTP proxy or from the local browser cache, and it's the part of HTTP protocol. Mostly the server which provide the data and not the client can influence on caching.
You can compare the requirement from your question with the requirement to prevent changing of IP address of the web server or the changing of the IP route during the communication. All the things can be interesting in some scenarios, but there are parts of another level of the communication stack and can't be managed by jQuery.ajax or XMLHttpRequest.
The XMLHttpRequest standard say that the client configuration can have options which prevent redirection. In case of "Microsoft world", which I better know, you can look at WinHttpSetOption function which can be used to set WINHTTP_OPTION_DISABLE_FEATURE option with the WINHTTP_DISABLE_REDIRECTS value. Another way are the usage of WINHTTP_OPTION_REDIRECT_POLICY option with the WINHTTP_OPTION_REDIRECT_POLICY_NEVER value. One more feature which one can use in Windows is the WinHttpSetStatusCallback function which can set callback function received some notifications like WINHTTP_CALLBACK_FLAG_REDIRECT.
So it's do possible to implement your requirements in general, but the solution will be probably not independent from the operation system or the web browser and be not on the level of jQuery.ajax or XMLHttpRequest.
I don't believe it is possible. The underlying library (XHR) makes the new request transparently. That being said, what I have done in these situations (usually a session-timeout type of deal that takes me to a login page) is send back a custom response header. I also have setup a global ajax handler that checks for the presence of that header, and responds appropriately when present (for example, redirecting the whole page to the login screen).
In case you're interested, here's the jQuery code I have to watch for that custom header:
/* redirects main window when AJAX request indicates that the session has expired on the backend. */
function checkSession(event, xhr, ajaxOptions)
{
if (xhr.readyState == 4)
{
if(xhr.getResponseHeader("Login-Screen") != null && xhr.getResponseHeader("Login-Screen").length)
{
window.location.href='sessionExpired.html'; //whatever
}
}
}
$(document).ajaxComplete(checkSession)
I found a feature to check if your call has been redirected. It's xhr.state(): if it's "rejected" then a redirection happened.
Example with success callback:
request.success(function(data, textStatus, xhr)
{
if(xhr.state() == "resolved")
{
//no redirection
}
if(xhr.state() == "rejected")
{
//redirection
}
});
Example with error callback:
request.error(function(xhr, textStatus)
{
if (xhr.state() == "rejected")
{
//redirection
location.href = "loginpage";
} else
{
//some other error happened
alert("error");
}
});
I can't possibly add to the insightful wisdom of the previous coders who've responded, but I will add a specific case that others may find useful to know about.
I came across this 302 silent redirect in the context of SharePoint. I have some simple Javascript client code that pings a SharePoint sub-site, and if it receives a 200 HTTP response, it relocates to that site, via window.location. If it receives anything else, it gives the user a notice that the site doesn't exist.
However, in the case where the site exists but the user does not have permission, SharePoint silently redirects to an AccessDenied.aspx page. SharePoint has already done the HTTP 401 authentication handshake at the server/farm level - the user has access to SharePoint. But the access to the sub-site is handled I suppose using database flags of some sort. The silent redirect bypasses my "else" clause, so I can't throw up my own error. In my case, this is not a show-stopper - it is consistent predictable behavior. But it was a little surprising, and I learned something about HTTP requests in the process!
I was interested in the same thing and could not find the state() method mentioned by Takman and did a little digging for myself. For the sake of people turning up here in search of an answer, here are my findings:
As stated multiple times, you cannot prevent redirects, but you can detect them. According to MDN you can use the responseURL of the XMLHttpRequestObject, which will contain the final URL the response came from, after all redirects. Only caveat is that it is not supported by Internet Explorer (Edge has it). Since the xhr/jqXHR passed into the success/done function of jquery is an extension of the actual XMLHttpRequest, it should be available there, too.
While it is not possible to disable location redirect following in XmlHttpRequests, it is when using fetch():
fetch('url', {redirect: manual});
I suppose you receive a 200 response because the second time there is no redirection, because the 404 page does not expire, it is saved in the cache. That is to say that the second time the browser gives you the page in the cache.
There is a property "cache" in the ajax jquery.
http://api.jquery.com/jQuery.ajax/
You should write it to "false"
I'm not sure if this will apply in your case, but you can write code to respond to specific status codes in AJAX function -
$.ajax({
url: '/admin/secret/data',
type: 'POST',
contentType: 'application/json; charset=utf-8',
statusCode: {
200: function (data) {
alert('302: Occurred');
// Bind the JSON data to the UI
},
401: function (data) {
alert('401: Occurred');
// Handle the 401 error here.
}
}
});
In the request headers in the case of ajax request you will have the following
X-Requested-With XMLHttpRequest
By this criteria on the server side you can filter requests.
I have a flash application that needs to send a http request to the server which will disconnect the existing session immediately. I have a tried a few options but none is reliable.
Option #1: On "onbeforeunload" event send a http request from inside the flash applications. Fallacy: This does not work because as soon as the browser is closed the flash player unloads the app and hence the communication breaks.
Option #2: On "onbeforeunload" event send a http request using XMLHTTPRequest in ajax. This works fine in IE but doesnt work in Firefox. When i debugged the http req in httpfox it threw "NS_BINDING_ABORTED" error which i think means that request was cancelled due to page unload.
Note that if i use an alert box, the requests are getting sent in both the options. But i cant use alert boxes. Is there any other way to do so ? or maybe kill the alert box after a timeout ?
It should not be the client's responsibility to tell the server it is disconnecting. You can make the client ping the server regularly to tell it it is still alive, or you could open an never-ending http request (comet-style), and fire the event when the tcp connection is broken.
In PHP it would look somehthing like this: (Not tested)
<?php
// Run script until aborted.
ignore_user_abort(true);
set_time_limit(0);
while(connection_status() == CONNECTION_NORMAL) {
sleep(1);
}
// The connection was lost, so do something.
onLostConnection();
?>
Anyway what was happening was that i was sending a crossdomain xmlhttprequest which is not allowed. see here, http://developer.yahoo.com/javascript/howto-proxy.html . I just fixed the urls and it worked in firefox as well.