Comment gérer une demande de redirection après un appel jQuery Ajax

J'utilise $.post()pour appeler un servlet en utilisant Ajax, puis en utilisant le fragment HTML résultant pour remplacer un divélément dans la page actuelle de l'utilisateur. Cependant, si la session expire, le serveur envoie une directive de redirection pour envoyer l'utilisateur à la page de connexion. Dans ce cas, jQuery remplace l' divélément par le contenu de la page de connexion, forçant les yeux de l'utilisateur à assister à une scène rare.

Comment puis-je gérer une directive de redirection à partir d'un appel Ajax avec jQuery 1.2.6?

J'ai lu cette question et mis en œuvre l'approche qui a été énoncée concernant la définition du code d'état HTTP de réponse à 278 afin d'éviter que le navigateur ne gère les redirections de manière transparente. Même si cela a fonctionné, j'étais un peu insatisfait car c'est un peu un hack.

Après avoir creusé davantage, j'ai abandonné cette approche et utilisé JSON . Dans ce cas, toutes les réponses aux demandes AJAX ont le code d'état 200 et le corps de la réponse contient un objet JSON qui est construit sur le serveur. Le JavaScript sur le client peut ensuite utiliser l'objet JSON pour décider de ce qu'il doit faire.

J'ai eu un problème similaire au vôtre. J'exécute une demande AJAX qui a 2 réponses possibles: une qui redirige le navigateur vers une nouvelle page et une qui remplace un formulaire HTML existant sur la page actuelle par un nouveau. Le code jQuery pour ce faire ressemble à ceci:

$.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);
        }
    }
});

L'objet JSON "données" est construit sur le serveur pour avoir 2 membres: data.redirectet data.form. J'ai trouvé que cette approche était bien meilleure.

J'ai résolu ce problème en:

1. Ajout d'un en-tête personnalisé à la réponse:

   public ActionResult Index(){
       if (!HttpContext.User.Identity.IsAuthenticated)
       {
           HttpContext.Response.AddHeader("REQUIRES_AUTH","1");
       }
       return View();
   }

2. Lier une fonction JavaScript à l' ajaxSuccessévénement et vérifier si l'en-tête existe:

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

Aucun navigateur ne gère correctement les réponses 301 et 302. Et en fait, la norme dit même qu'ils devraient les gérer "de manière transparente", ce qui est un casse-tête MASSIVE pour les fournisseurs de la bibliothèque Ajax. Dans Ra-Ajax, nous avons été contraints d'utiliser le code d'état de réponse HTTP 278 (juste un code de réussite "inutilisé") pour gérer les redirections transparentes depuis le serveur ...

Cela m'énerve vraiment, et si quelqu'un ici a du "pull" dans le W3C, j'apprécierais que vous puissiez faire savoir au W3C que nous devons vraiment gérer nous-mêmes les codes 301 et 302 ...! ;)

La solution qui a finalement été implémentée était d'utiliser un wrapper pour la fonction de rappel de l'appel Ajax et dans ce wrapper de vérifier l'existence d'un élément spécifique sur le morceau HTML renvoyé. Si l'élément a été trouvé, le wrapper a exécuté une redirection. Sinon, l'encapsuleur a transféré l'appel à la fonction de rappel réelle.

Par exemple, notre fonction wrapper était quelque chose comme:

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

Ensuite, lors de l'appel Ajax, nous avons utilisé quelque chose comme:

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

Cela a fonctionné pour nous car tous les appels Ajax renvoyaient toujours du HTML dans un élément DIV que nous utilisons pour remplacer une partie de la page. De plus, nous avions seulement besoin de rediriger vers la page de connexion.

J'aime la méthode de Timmerz avec une légère touche de citron. Si vous obtenez un contentType de texte / html retourné lorsque vous attendez JSON , vous êtes très probablement redirigé. Dans mon cas, je recharge simplement la page et elle est redirigée vers la page de connexion. Oh, et vérifiez que l'état jqXHR est 200, ce qui semble idiot, car vous êtes dans la fonction d'erreur, non? Sinon, les cas d'erreur légitimes forceront un rechargement itératif (oups)

$.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();
    }

});

Utilisez l' $.ajax()appel de bas niveau :

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

Essayez ceci pour une redirection:

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

Je voulais juste partager mon approche car cela pourrait aider quelqu'un:

J'ai essentiellement inclus un module JavaScript qui gère les éléments d'authentification comme l'affichage du nom d'utilisateur et également ce cas, la gestion de la redirection vers la page de connexion .

Mon scénario: Nous avons essentiellement un serveur ISA entre les deux qui écoute toutes les demandes et répond avec un 302 et un en-tête d'emplacement à notre page de connexion.

Dans mon module JavaScript, mon approche initiale était quelque chose comme

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

Le problème (comme beaucoup ici déjà mentionné) est que le navigateur gère lui-même la redirection, c'est pourquoi mon ajaxCompleterappel n'a jamais été appelé, mais à la place, j'ai obtenu la réponse de la page de connexion déjà redirigée qui était évidemment un status 200. Le problème: comment détecter si la réponse 200 réussie est votre page de connexion réelle ou simplement une autre page arbitraire ??

La solution

Comme je n'ai pas pu capturer 302 réponses de redirection, j'ai ajouté un en- LoginPagetête sur ma page de connexion qui contenait l'url de la page de connexion elle-même. Dans le module, j'écoute maintenant l'en-tête et fais une redirection:

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

... et ça marche comme du charme :). Vous vous demandez peut-être pourquoi j'inclus l'URL dans l'en- LoginPagetête ... enfin, fondamentalement parce que je n'ai trouvé aucun moyen de déterminer l'URL GETrésultant de la redirection automatique de l'emplacement depuis l' xhrobjet ...

Je sais que ce sujet est ancien, mais je donnerai une autre approche que j'ai trouvée et décrite précédemment ici . Fondamentalement, j'utilise ASP.MVC avec WIF (mais ce n'est pas vraiment important pour le contexte de ce sujet - la réponse est adéquate quel que soit le cadre utilisé. L'indice reste inchangé - traitant des problèmes liés aux échecs d'authentification lors de l'exécution de requêtes ajax ) .

L'approche illustrée ci-dessous peut être appliquée à toutes les demandes ajax prédéfinies (si elles ne sont pas redéfinies avant l'événement Send évidemment).

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

Avant toute requête ajax, la CheckPulseméthode est invoquée (la méthode du contrôleur qui peut être la plus simple):

[Authorize]
public virtual void CheckPulse() {}

Si l'utilisateur n'est pas authentifié (le jeton a expiré), cette méthode n'est pas accessible (protégée par un Authorizeattribut). Étant donné que le framework gère l'authentification, tandis que le jeton expire, il place l'état http 302 dans la réponse. Si vous ne voulez pas que votre navigateur gère la réponse 302 de manière transparente, interceptez-la dans Global.asax et modifiez l'état de la réponse, par exemple 200 OK. De plus, ajoutez un en-tête, qui vous demande de traiter une telle réponse de manière spéciale (plus tard du côté client):

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

Enfin, côté client, vérifiez cet en-tête personnalisé. Si présent - une redirection complète vers la page de connexion doit être effectuée (dans mon cas, window.locationest remplacée par l'URL de la demande qui est gérée automatiquement par mon 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;
                }
            }
    });
}

Je pense qu'une meilleure façon de gérer cela est de tirer parti des codes de réponse du protocole HTTP existants, en particulier 401 Unauthorized.

Voici comment je l'ai résolu:

1. Côté serveur: si la session expire et que la demande est ajax. envoyer un en-tête de code de réponse 401

2. Côté client: se lier aux événements ajax

   $('body').bind('ajaxSuccess',function(event,request,settings){
   if (401 == request.status){
       window.location = '/users/login';
   }
   }).bind('ajaxError',function(event,request,settings){
   if (401 == request.status){
       window.location = '/users/login';
   }
   });

OMI, c'est plus générique et vous n'écrivez pas de nouvelles spécifications / en-têtes personnalisés. Vous ne devriez pas non plus avoir à modifier aucun de vos appels ajax existants.

Edit: Selon le commentaire de @ Rob ci-dessous, 401 (le code d'état HTTP pour les erreurs d'authentification) devrait être l'indicateur. Voir 403 Interdit vs 401 Réponses HTTP non autorisées pour plus de détails. Cela étant dit, certains cadres Web utilisent 403 pour les erreurs d'authentification ET d'autorisation - alors adaptez-vous en conséquence. Merci Rob.

J'ai résolu ce problème comme ceci:

Ajoutez un middleware pour traiter la réponse, s'il s'agit d'une redirection pour une demande ajax, modifiez la réponse en une réponse normale avec l'URL de redirection.

class AjaxRedirect(object):
  def process_response(self, request, response):
    if request.is_ajax():
      if type(response) == HttpResponseRedirect:
        r = HttpResponse(json.dumps({'redirect': response['Location']}))
        return r
    return response

Ensuite, dans ajaxComplete, si la réponse contient une redirection, il doit s'agir d'une redirection, alors changez l'emplacement du navigateur.

$('body').ajaxComplete(function (e, xhr, settings) {
   if (xhr.status == 200) {
       var redirect = null;
       try {
           redirect = $.parseJSON(xhr.responseText).redirect;
           if (redirect) {
               window.location.href = redirect.replace(/\?.*$/, "?next=" + window.location.pathname);
           }
       } catch (e) {
           return;
       }
   }
}

J'ai une solution simple qui fonctionne pour moi, aucun changement de code de serveur nécessaire ... il suffit d'ajouter une cuillère à café de muscade ...

$(document).ready(function ()
{
    $(document).ajaxSend(
    function(event,request,settings)
    {
        var intercepted_success = settings.success;
        settings.success = function( a, b, c ) 
        {  
            if( request.responseText.indexOf( "<html>" ) > -1 )
                window.location = window.location;
            else
                intercepted_success( a, b, c );
        };
    });
});

Je vérifie la présence de la balise html, mais vous pouvez modifier l'indexOf pour rechercher la chaîne unique qui existe dans votre page de connexion ...

Une autre solution que j'ai trouvée (particulièrement utile si vous souhaitez définir un comportement global) consiste à utiliser la $.ajaxsetup()méthode avec la statusCodepropriété . Comme d'autres l'ont souligné, n'utilisez pas de code d'état de redirection ( 3xx), utilisez plutôt un 4xxcode d'état et gérez la redirection côté client.

$.ajaxSetup({ 
  statusCode : {
    400 : function () {
      window.location = "/";
    }
  }
});

Remplacez 400par le code d'état que vous souhaitez gérer. Comme déjà mentionné, cela 401 Unauthorizedpourrait être une bonne idée. J'utilise le 400car il est très peu spécifique et je peux l'utiliser 401pour des cas plus spécifiques (comme des informations de connexion erronées). Ainsi, au lieu de rediriger directement, votre backend devrait renvoyer un 4xxcode d'erreur lorsque la session a expiré et que vous gérez la redirection côté client. Fonctionne parfaitement pour moi même avec des frameworks comme backbone.js

La plupart des solutions données utilisent une solution de contournement, en utilisant un en-tête supplémentaire ou un code HTTP inapproprié. Ces solutions fonctionneront très probablement mais se sentiront un peu «hacky». J'ai trouvé une autre solution.

Nous utilisons WIF qui est configuré pour rediriger (passiveRedirectEnabled = "true") sur une réponse 401. La redirection est utile lors du traitement des requêtes normales mais ne fonctionnera pas pour les requêtes AJAX (puisque les navigateurs n'exécuteront pas la redirection 302 /).

En utilisant le code suivant dans votre global.asax, vous pouvez désactiver la redirection pour les demandes AJAX:

    void WSFederationAuthenticationModule_AuthorizationFailed(object sender, AuthorizationFailedEventArgs e)
    {
        string requestedWithHeader = HttpContext.Current.Request.Headers["X-Requested-With"];

        if (!string.IsNullOrEmpty(requestedWithHeader) && requestedWithHeader.Equals("XMLHttpRequest", StringComparison.OrdinalIgnoreCase))
        {
            e.RedirectToIdentityProvider = false;
        }
    }

Cela vous permet de renvoyer 401 réponses pour les demandes AJAX, que votre javascript peut ensuite gérer en rechargeant la page. Le rechargement de la page lancera un 401 qui sera géré par WIF (et WIF redirigera l'utilisateur vers la page de connexion).

Un exemple de javascript pour gérer les erreurs 401:

$(document).ajaxError(function (event, jqxhr, settings, exception) {

    if (jqxhr.status == 401) { //Forbidden, go to login
        //Use a reload, WIF will redirect to Login
        location.reload(true);
    }
});

Ce problème peut apparaître lors de l'utilisation de la méthode ASP.NET MVC RedirectToAction. Pour empêcher le formulaire d'afficher la réponse en div, vous pouvez simplement faire une sorte de filtre de réponse ajax pour les réponses entrantes avec $ .ajaxSetup . Si la réponse contient une redirection MVC, vous pouvez évaluer cette expression du côté JS. Exemple de code pour JS ci-dessous:

$.ajaxSetup({
    dataFilter: function (data, type) {
        if (data && typeof data == "string") {
            if (data.indexOf('window.location') > -1) {
                eval(data);
            }
        }
        return data;
    }
});

Si les données sont: "window.location = '/ Acount / Login'" ci-dessus, le filtre interceptera et évaluera pour effectuer la redirection au lieu de laisser les données à afficher.

Réunissant ce que Vladimir Prudnikov et Thomas Hansen ont dit:

• Modifiez votre code côté serveur pour détecter s'il s'agit d'un XHR. Si c'est le cas, définissez le code de réponse de la redirection sur 278. Dans django:

   if request.is_ajax():
      response.status_code = 278

Cela fait que le navigateur traite la réponse comme un succès et la transmet à votre Javascript.

• Dans votre JS, assurez-vous que la soumission du formulaire se fait via Ajax, vérifiez le code de réponse et redirigez si nécessaire:

$('#my-form').submit(function(event){ 

  event.preventDefault();   
  var options = {
    url: $(this).attr('action'),
    type: 'POST',
    complete: function(response, textStatus) {    
      if (response.status == 278) { 
        window.location = response.getResponseHeader('Location')
      }
      else { ... your code here ... } 
    },
    data: $(this).serialize(),   
  };   
  $.ajax(options); 
});

    <script>
    function showValues() {
        var str = $("form").serialize();
        $.post('loginUser.html', 
        str,
        function(responseText, responseStatus, responseXML){
            if(responseStatus=="success"){
                window.location= "adminIndex.html";
            }
        });     
    }
</script>

Essayer

    $(document).ready(function () {
        if ($("#site").length > 0) {
            window.location = "<%= Url.Content("~") %>" + "Login/LogOn";
        }
    });

Mettez-le sur la page de connexion. S'il a été chargé dans un div sur la page principale, il sera redirigé jusqu'à la page de connexion. "#site" est un identifiant de div qui se trouve sur toutes les pages sauf la page de connexion.

Bien que les réponses semblent fonctionner pour les gens si vous utilisez Spring Security, j'ai trouvé l'extension de LoginUrlAuthenticationEntryPoint et l'ajout de code spécifique pour gérer AJAX plus robuste. La plupart des exemples interceptent toutes les redirections, pas seulement les échecs d'authentification. Ce n'était pas souhaitable pour le projet sur lequel je travaille. Vous devrez peut-être également étendre ExceptionTranslationFilter et remplacer la méthode "sendStartAuthentication" pour supprimer l'étape de mise en cache si vous ne voulez pas que la demande AJAX en échec soit mise en cache.

Exemple AjaxAwareAuthenticationEntryPoint:

public class AjaxAwareAuthenticationEntryPoint extends
    LoginUrlAuthenticationEntryPoint {

    public AjaxAwareAuthenticationEntryPoint(String loginUrl) {
        super(loginUrl);
    }

    @Override
    public void commence(HttpServletRequest request, HttpServletResponse response, AuthenticationException authException) throws IOException, ServletException {
        if (isAjax(request)) {
            response.sendError(HttpStatus.UNAUTHORIZED.value(), "Please re-authenticate yourself");
        } else {
        super.commence(request, response, authException);
        }
    }

    public static boolean isAjax(HttpServletRequest request) {
        return request != null && "XMLHttpRequest".equals(request.getHeader("X-Requested-With"));
    }
}

Sources: 1 , 2

J'ai résolu cela en mettant ce qui suit dans ma page login.php.

<script type="text/javascript">
    if (top.location.href.indexOf('login.php') == -1) {
        top.location.href = '/login.php';
    }
</script>

Permettez-moi de citer à nouveau le problème décrit par @Steg

J'ai eu un problème similaire au vôtre. J'effectue une requête ajax qui a 2 réponses possibles: une qui redirige le navigateur vers une nouvelle page et une qui remplace un formulaire HTML existant sur la page actuelle par un nouveau.

À mon humble avis, il s'agit d'un véritable défi et devra être officiellement étendu aux normes HTTP actuelles.

Je crois que la nouvelle norme Http sera d'utiliser un nouveau code d'état. Signification: 301/302indique actuellement au navigateur d'aller chercher le contenu de cette demande dans une nouvelle location.

Dans le standard étendu, il dira que si la réponse status: 308(juste un exemple), alors le navigateur devrait rediriger la page principale vers la locationfournie.

Cela étant dit; Je suis enclin à imiter déjà ce comportement futur , et donc quand un document.redirect est nécessaire, je demande au serveur de répondre comme:

status: 204 No Content
x-status: 308 Document Redirect
x-location: /login.html

Lorsque JS obtient le " status: 204", il vérifie l'existence de l'en- x-status: 308tête et fait un document.redirect à la page fournie dans l'en- locationtête.

Est-ce que cela a un sens pour vous?

Certains pourraient trouver les informations ci-dessous utiles:

Je voulais que les clients soient redirigés vers la page de connexion pour toute action de repos envoyée sans jeton d'autorisation. Étant donné que toutes mes actions de repos sont basées sur Ajax, j'avais besoin d'un bon moyen générique pour rediriger vers la page de connexion au lieu de gérer la fonction de réussite Ajax.

Voici ce que j'ai fait:

Sur toute demande Ajax, mon serveur retournera une réponse Json 200 "BESOIN D'AUTHENTIFIER" (si le client a besoin de s'authentifier).

Exemple simple en Java (côté serveur):

@Secured
@Provider
@Priority(Priorities.AUTHENTICATION)
public class AuthenticationFilter implements ContainerRequestFilter {

    private final Logger m_logger = LoggerFactory.getLogger(AuthenticationFilter.class);

    public static final String COOKIE_NAME = "token_cookie"; 

    @Override
    public void filter(ContainerRequestContext context) throws IOException {        
        // Check if it has a cookie.
        try {
            Map<String, Cookie> cookies = context.getCookies();

            if (!cookies.containsKey(COOKIE_NAME)) {
                m_logger.debug("No cookie set - redirect to login page");
                throw new AuthenticationException();
            }
        }
        catch (AuthenticationException e) {
            context.abortWith(Response.ok("\"NEED TO AUTHENTICATE\"").type("json/application").build());
        }
    }
}

Dans mon Javascript, j'ai ajouté le code suivant:

$.ajaxPrefilter(function(options, originalOptions, jqXHR) {
    var originalSuccess = options.success;

    options.success = function(data) {
        if (data == "NEED TO AUTHENTICATE") {
            window.location.replace("/login.html");
        }
        else {
            originalSuccess(data);
        }
    };      
});

Et c'est tout.

dans le servlet, vous devez mettre response.setStatus(response.SC_MOVED_PERMANENTLY); pour envoyer le statut xmlHttp '301' dont vous avez besoin pour une redirection ...

et dans la fonction $ .ajax vous ne devez pas utiliser la .toString()fonction ..., juste

if (xmlHttp.status == 301) { top.location.href = 'xxxx.jsp'; }

le problème est qu'il n'est pas très flexible, vous ne pouvez pas décider où vous souhaitez rediriger ..

la redirection via les servlets devrait être le meilleur moyen. mais je ne trouve toujours pas la bonne façon de le faire.

Je voulais juste m'accrocher à toutes les demandes ajax pour la page entière. @SuperG m'a fait démarrer. Voici ce que j'ai fini avec:

// redirect ajax requests that are redirected, not found (404), or forbidden (403.)
$('body').bind('ajaxComplete', function(event,request,settings){
        switch(request.status) {
            case 301: case 404: case 403:                    
                window.location.replace("http://mysite.tld/login");
                break;
        }
});

Je voulais vérifier spécifiquement certains codes de statut http sur lesquels baser ma décision. Cependant, vous pouvez simplement vous lier à ajaxError pour obtenir autre chose que du succès (200 seulement peut-être?) J'aurais pu écrire:

$('body').bind('ajaxError', function(event,request,settings){
    window.location.replace("http://mysite.tld/login");
}

Si vous souhaitez également transmettre les valeurs, vous pouvez également définir les variables de session et accéder par exemple: dans votre jsp, vous pouvez écrire

<% HttpSession ses = request.getSession(true);
   String temp=request.getAttribute("what_you_defined"); %>

Et puis vous pouvez stocker cette valeur temporaire dans votre variable javascript et jouer

Je n'ai eu aucun succès avec la solution d'en-tête - ils n'ont jamais été récupérés dans ma méthode ajaxSuccess / ajaxComplete. J'ai utilisé la réponse de Steg avec la réponse personnalisée, mais j'ai modifié certains côté JS. J'ai configuré une méthode que j'appelle dans chaque fonction afin que je puisse utiliser les méthodes $.getet standards $.post.

function handleAjaxResponse(data, callback) {
    //Try to convert and parse object
    try {
        if (jQuery.type(data) === "string") {
            data = jQuery.parseJSON(data);
        }
        if (data.error) {
            if (data.error == 'login') {
                window.location.reload();
                return;
            }
            else if (data.error.length > 0) {
                alert(data.error);
                return;
            }
        }
    }
    catch(ex) { }

    if (callback) {
        callback(data);
    }
}

Exemple d'utilisation ...

function submitAjaxForm(form, url, action) {
    //Lock form
    form.find('.ajax-submit').hide();
    form.find('.loader').show();

    $.post(url, form.serialize(), function (d) {
        //Unlock form
        form.find('.ajax-submit').show();
        form.find('.loader').hide();

        handleAjaxResponse(d, function (data) {
            // ... more code for if auth passes ...
        });
    });
    return false;
}

Enfin, je résous le problème en ajoutant une coutume HTTP Header. Juste avant la réponse pour chaque demande côté serveur, j'ajoute l'URL actuellement demandée à l'en-tête de la réponse.

Mon type d'application sur le serveur est Asp.Net MVC, et il a un bon endroit pour le faire. en Global.asaxj'ai implémenté l' Application_EndRequestévénement donc:

    public class MvcApplication : System.Web.HttpApplication
    {

    //  ...
    //  ...

        protected void Application_EndRequest(object sender, EventArgs e)
        {
            var app = (HttpApplication)sender;
            app.Context.Response.Headers.Add("CurrentUrl",app.Context. Request.CurrentExecutionFilePath);
        }

    }

Cela fonctionne parfaitement pour moi! Maintenant , dans chaque réponse du JQuery $.postj'ai demandé les en- urltêtes de réponse et aussi d' autres qui vient à la suite de la POSTméthode par le statut 302, 303....

et une autre chose importante est qu'il n'est pas nécessaire de modifier le code côté serveur ou côté client.

et le suivant est la possibilité d'accéder aux autres informations de post-action telles que les erreurs, les messages et ..., de cette façon.

J'ai posté ça, peut-être aider quelqu'un :)

J'avais ce problème sur une application django avec laquelle je bricolais (avertissement: je bricole pour apprendre, et je ne suis en aucun cas un expert). Ce que je voulais faire, c'était utiliser jQuery ajax pour envoyer une demande DELETE à une ressource, la supprimer côté serveur, puis renvoyer une redirection vers (essentiellement) la page d'accueil. Quand j'ai envoyé à HttpResponseRedirect('/the-redirect/')partir du script python, la méthode ajax de jQuery recevait 200 au lieu de 302. Donc, ce que j'ai fait était d'envoyer une réponse de 300 avec:

response = HttpResponse(status='300')
response['Location'] = '/the-redirect/' 
return  response

Ensuite, j'ai envoyé / traité la demande sur le client avec jQuery.ajax comme ceci:

<button onclick="*the-jquery*">Delete</button>

where *the-jquery* =
$.ajax({ 
  type: 'DELETE', 
  url: '/resource-url/', 
  complete: function(jqxhr){ 
    window.location = jqxhr.getResponseHeader('Location'); 
  } 
});

Peut-être que l'utilisation de 300 n'est pas "correcte", mais au moins cela a fonctionné comme je le voulais.

PS: ce fut une énorme douleur à éditer sur la version mobile de SO. Stupide FAI a traité ma demande d'annulation de service juste après avoir fini avec ma réponse!

Vous pouvez également accrocher le prototype d'envoi XMLHttpRequest. Cela fonctionnera pour tous les envois (jQuery / dojo / etc) avec un gestionnaire.

J'ai écrit ce code pour gérer une erreur expirée de 500 pages, mais cela devrait aussi bien fonctionner pour intercepter une redirection 200. Préparez l'entrée wikipedia sur XMLHttpRequest onreadystatechange sur la signification de readyState.

// Hook XMLHttpRequest
var oldXMLHttpRequestSend = XMLHttpRequest.prototype.send;

XMLHttpRequest.prototype.send = function() {
  //console.dir( this );

  this.onreadystatechange = function() {
    if (this.readyState == 4 && this.status == 500 && this.responseText.indexOf("Expired") != -1) {
      try {
        document.documentElement.innerHTML = this.responseText;
      } catch(error) {
        // IE makes document.documentElement read only
        document.body.innerHTML = this.responseText;
      }
    }
  };

  oldXMLHttpRequestSend.apply(this, arguments);
}

De plus, vous souhaiterez probablement rediriger l'utilisateur vers l'URL indiquée dans les en-têtes. Donc, finalement, cela ressemblera à ceci:

$.ajax({
    //.... other definition
    complete:function(xmlHttp){
        if(xmlHttp.status.toString()[0]=='3'){
        top.location.href = xmlHttp.getResponseHeader('Location');
    }
});

UPD: Opps. Ont la même tâche, mais cela ne fonctionne pas. Faire ce genre de choses. Je vous montrerai une solution quand je la trouverai.

Je suis un solulion de travail en utilisant les réponses de @John et @Arpad lien et @RobWinch lien

J'utilise Spring Security 3.2.9 et jQuery 1.10.2.

Étendez la classe de Spring pour provoquer une réponse 4XX uniquement à partir des requêtes AJAX:

public class CustomLoginUrlAuthenticationEntryPoint extends LoginUrlAuthenticationEntryPoint {

    public CustomLoginUrlAuthenticationEntryPoint(final String loginFormUrl) {
        super(loginFormUrl);
    }

    // For AJAX requests for user that isn't logged in, need to return 403 status.
    // For normal requests, Spring does a (302) redirect to login.jsp which the browser handles normally.
    @Override
    public void commence(final HttpServletRequest request,
                         final HttpServletResponse response,
                         final AuthenticationException authException)
            throws IOException, ServletException {
        if ("XMLHttpRequest".equals(request.getHeader("X-Requested-With"))) {
            response.sendError(HttpServletResponse.SC_FORBIDDEN, "Access Denied");
        } else {
            super.commence(request, response, authException);
        }
    }
}

applicationContext-security.xml

  <security:http auto-config="false" use-expressions="true" entry-point-ref="customAuthEntryPoint" >
    <security:form-login login-page='/login.jsp' default-target-url='/index.jsp'                             
                         authentication-failure-url="/login.jsp?error=true"
                         />    
    <security:access-denied-handler error-page="/errorPage.jsp"/> 
    <security:logout logout-success-url="/login.jsp?logout" />
...
    <bean id="customAuthEntryPoint" class="com.myapp.utils.CustomLoginUrlAuthenticationEntryPoint" scope="singleton">
        <constructor-arg value="/login.jsp" />
    </bean>
...
<bean id="requestCache" class="org.springframework.security.web.savedrequest.HttpSessionRequestCache">
    <property name="requestMatcher">
      <bean class="org.springframework.security.web.util.matcher.NegatedRequestMatcher">
        <constructor-arg>
          <bean class="org.springframework.security.web.util.matcher.MediaTypeRequestMatcher">
            <constructor-arg>
              <bean class="org.springframework.web.accept.HeaderContentNegotiationStrategy"/>
            </constructor-arg>
            <constructor-arg value="#{T(org.springframework.http.MediaType).APPLICATION_JSON}"/>
            <property name="useEquals" value="true"/>
          </bean>
        </constructor-arg>
      </bean>
    </property>
</bean>

Dans mes JSP, ajoutez un gestionnaire d'erreur AJAX global comme indiqué ici

  $( document ).ajaxError(function( event, jqxhr, settings, thrownError ) {
      if ( jqxhr.status === 403 ) {
          window.location = "login.jsp";
      } else {
          if(thrownError != null) {
              alert(thrownError);
          } else {
              alert("error");
          }
      }
  });

Supprimez également les gestionnaires d'erreurs existants des appels AJAX dans les pages JSP:

        var str = $("#viewForm").serialize();
        $.ajax({
            url: "get_mongoDB_doc_versions.do",
            type: "post",
            data: str,
            cache: false,
            async: false,
            dataType: "json",
            success: function(data) { ... },
//            error: function (jqXHR, textStatus, errorStr) {
//                 if(textStatus != null)
//                     alert(textStatus);
//                 else if(errorStr != null)
//                     alert(errorStr);
//                 else
//                     alert("error");
//            }
        });

J'espère que cela aide les autres.

Update1 J'ai trouvé que je devais ajouter l'option (always-use-default-target = "true") à la configuration de connexion au formulaire. Cela était nécessaire car après qu'une demande AJAX a été redirigée vers la page de connexion (en raison de la session expirée), Spring se souvient de la demande AJAX précédente et y redirige automatiquement après la connexion. Cela provoque l'affichage du JSON renvoyé sur la page du navigateur. Bien sûr, pas ce que je veux.

Update2 Au lieu d'utiliser always-use-default-target="true", utilisez l'exemple @RobWinch de blocage des requêtes AJAX à partir du requstCache. Cela permet aux liens normaux d'être redirigés vers leur cible d'origine après la connexion, mais AJAX accède à la page d'accueil après la connexion.