Вопрос: Как управлять запросом перенаправления после вызова jQuery Ajax


я использую $.post()для вызова сервлета с использованием Ajax, а затем с помощью полученного фрагмента HTML заменить divэлемент на текущей странице пользователя. Однако, если сеанс истекает, сервер отправляет директиву перенаправления для отправки пользователя на страницу входа. В этом случае jQuery заменяет divэлемент с содержимым страницы входа, заставляя глаза пользователя засвидетельствовать редкую сцену.

Как я могу управлять директивой перенаправления от вызова Ajax с помощью jQuery 1.2.6?


1166


источник


Ответы:


Я прочитал этот вопрос и внедрил подход, который был сформулирован в отношении установки кода статуса ответа на 278, чтобы избежать прозрачности работы браузера с переадресацией. Несмотря на то, что это сработало, я был немного недоволен, так как это немного взломан.

После дальнейшего копания я бросил этот подход и использовал JSON , В этом случае все ответы на запросы ajax имеют код состояния 200, а тело ответа содержит объект JSON, который построен на сервере. Затем javascript на клиенте может использовать объект JSON, чтобы решить, что ему нужно делать.

У меня была схожая проблема с твоей. Я выполняю запрос ajax, который имеет 2 возможных ответа: один, который перенаправляет браузер на новую страницу и заменяет существующую HTML-форму на текущей странице новой. Код jquery для этого выглядит примерно так:

$.ajax({
    type: "POST",
    url: reqUrl,
    data: reqBody,
    dataType: "json",
    success: function(data, textStatus) {
        if (data.redirect) {
            // data.redirect contains the string URL to redirect to
            window.location.href = data.redirect;
        }
        else {
            // data.form contains the HTML for the replacement form
            $("#myform").replaceWith(data.form);
        }
    }
});

Объектные «данные» объекта JSON построены на сервере, чтобы иметь 2 члена: data.redirect и data.form. Я нашел этот подход намного лучше.


624



Я решил эту проблему:

  1. Добавление настраиваемого заголовка в ответ:

    public ActionResult Index(){
        if (!HttpContext.User.Identity.IsAuthenticated)
        {
            HttpContext.Response.AddHeader("REQUIRES_AUTH","1");
        }
        return View();
    }
    
  2. Связывание функции JavaScript с ajaxSuccessсобытия и проверки, чтобы увидеть, существует ли заголовок:

    $(document).ajaxSuccess(function(event, request, settings) {
        if (request.getResponseHeader('REQUIRES_AUTH') === '1') {
           window.location = '/';
        }
    });
    

208



Никакие браузеры не обрабатывают 301 и 302 ответов правильно. И на самом деле стандарт даже говорит, что они должны обрабатывать их «прозрачно», что является МАССИВНОЙ головной болью для поставщиков библиотеки Ajax. В Ра-Ajax мы были вынуждены использовать HTTP-код ответа HTTP 278 (только некоторый «неиспользуемый» код успеха) для прозрачной переадресации с сервера ...

Это меня действительно раздражает, и если у кого-то здесь есть «тяга» в W3C, я был бы признателен, что вы могли бы позволить W3C знать что нам действительно нужно обрабатывать 301 и 302 коды ...! ;)


105



Решение, которое в конечном итоге было реализовано, состояло в том, чтобы использовать оболочку для функции обратного вызова вызова Ajax и в этой проверке обертки для существования определенного элемента в возвращаемом блоке HTML. Если элемент был найден, оболочка выполнила перенаправление. В противном случае обертка переадресовала вызов фактической функции обратного вызова.

Например, наша оберточная функция была примерно такой:

function cbWrapper(data, funct){
    if($("#myForm", data).length > 0)
        top.location.href="login.htm";//redirection
    else
        funct(data);
}

Затем, когда мы вызывали вызов Ajax, мы использовали что-то вроде:

$.post("myAjaxHandler", 
       {
        param1: foo,
        param2: bar
       },
       function(data){
           cbWrapper(data, myActualCB);
       }, 
       "html"
);

Это сработало для нас, потому что все вызовы Ajax всегда возвращают HTML внутри элемента DIV, который мы используем для замены части страницы. Кроме того, нам нужно было перенаправить на страницу входа в систему.


83



Мне нравится метод Тиммерса с небольшим завихрением лимона. Если вы когда-нибудь вернетесь Тип содержимого из текст / html когда вы ожидаете JSON , вы, скорее всего, будете перенаправлены. В моем случае я просто перезагружаю страницу и перенаправляется на страницу входа. О, и проверьте, что состояние jqXHR равно 200, что кажется глупым, потому что вы находитесь в функции ошибки, верно? В противном случае допустимые ошибки приведут к повторной перезагрузке (oops)

$.ajax(
   error:  function (jqXHR, timeout, message) {
    var contentType = jqXHR.getResponseHeader("Content-Type");
    if (jqXHR.status === 200 && contentType.toLowerCase().indexOf("text/html") >= 0) {
        // assume that our login has expired - reload our current page
        window.location.reload();
    }

});

56



Use the low-level $.ajax() call:

$.ajax({
  url: "/yourservlet",
  data: { },
  complete: function(xmlHttp) {
    // xmlHttp is a XMLHttpRquest object
    alert(xmlHttp.status);
  }
});

Try this for a redirect:

if (xmlHttp.code != 200) {
  top.location.href = '/some/other/page';
}

44



I just wanted to share my approach as this might it might help someone:

I basically included a JavaScript module which handles the authentication stuff like displaying the username and also this case handling the redirect to the login page.

My scenario: We basically have an ISA server in between which listens to all requests and responds with a 302 and a location header to our login page.

In my JavaScript module my initial approach was something like

$(document).ajaxComplete(function(e, xhr, settings){
    if(xhr.status === 302){
        //check for location header and redirect...
    }
});

The problem (as many here already mentioned) is that the browser handles the redirect by itself wherefore my ajaxComplete callback got never called, but instead I got the response of the already redirected Login page which obviously was a status 200. The problem: how do you detect whether the successful 200 response is your actual login page or just some other arbitrary page??

The solution

Since I was not able to capture 302 redirect responses, I added a LoginPage header on my login page which contained the url of the login page itself. In the module I now listen for the header and do a redirect:

if(xhr.status === 200){
    var loginPageRedirectHeader = xhr.getResponseHeader("LoginPage");
    if(loginPageRedirectHeader && loginPageRedirectHeader !== ""){
        window.location.replace(loginPageRedirectHeader);
    }
}

...and that works like charm :). You might wonder why I include the url in the LoginPage header...well basically because I found no way of determining the url of GET resulting from the automatic location redirect from the xhr object...


31



I know this topic is old, but I'll give yet another approach I've found and previously described here. Basically I'm using ASP.MVC with WIF (but this is not really important for the context of this topic - answer is adequate no matter which frameworks are used. The clue stays unchanged - dealing with issues related to authentication failures while performing ajax requests).

The approach shown below can be applied to all ajax requests out of the box (if they do not redefine beforeSend event obviously).

$.ajaxSetup({
    beforeSend: checkPulse,
    error: function (XMLHttpRequest, textStatus, errorThrown) {
        document.open();
        document.write(XMLHttpRequest.responseText);
        document.close();
    }
});

Before any ajax request is performed CheckPulse method is invoked (the controller method which can be anything simplest):

[Authorize]
public virtual void CheckPulse() {}

If user is not authenticated (token has expired) such method cannot be accessed (protected by Authorize attribute). Because the framework handles authentication, while token expires, it puts http status 302 to the response. If you don't want your browser to handle 302 response transparently, catch it in Global.asax and change response status - for example to 200 OK. Additionally, add header, which instructs you to process such response in special way (later at the client side):

protected void Application_EndRequest()
{
    if (Context.Response.StatusCode == 302
        && (new HttpContextWrapper(Context)).Request.IsAjaxRequest())
    {                
        Context.Response.StatusCode = 200;
        Context.Response.AddHeader("REQUIRES_AUTH", "1");
    }
}

Finally at the client side check for such custom header. If present - full redirection to logon page should be done (in my case window.location is replaced by url from request which is handled automatically by my framework).

function checkPulse(XMLHttpRequest) {
    var location = window.location.href;
    $.ajax({
        url: "/Controller/CheckPulse",
        type: 'GET',
        async: false,
        beforeSend: null,
        success:
            function (result, textStatus, xhr) {
                if (xhr.getResponseHeader('REQUIRES_AUTH') === '1') {
                    XMLHttpRequest.abort(); // terminate further ajax execution
                    window.location = location;
                }
            }
    });
}

26