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

Question

J'utilise $.post() pour appeler une servlet à l'aide d'Ajax, puis en utilisant le fragment HTML résultant pour remplacer un fichier de type div dans la page actuelle de l'utilisateur. Toutefois, si la session expire, le serveur envoie une directive de redirection pour renvoyer l'utilisateur vers la page de connexion. Dans ce cas, jQuery remplace l'élément div avec le contenu de la page de connexion, obligeant les yeux de l'utilisateur à assister à une scène rare.

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

Answer 1

J'ai lu cette question et j'ai mis en œuvre l'approche qui a été indiquée concernant la définition de la réponse Code d'état HTTP à 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 mécontent car c'est un peu un hack.

Après avoir creusé un peu plus, j'ai abandonné cette approche et j'ai utilisé JSON . Dans ce cas, toutes les réponses aux requêtes AJAX ont l'attribut code de statut 200 et le corps de la réponse contient un objet JSON qui est construit sur le serveur. Le JavaScript du client peut alors 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 requête AJAX qui a 2 réponses possibles : une qui redirige vers le navigateur à une nouvelle page et une qui remplace un formulaire HTML existant sur la page actuelle avec un nouveau formulaire. Le code jQuery pour faire cela ressemble à quelque chose comme :

$.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 "data" est construit sur le serveur pour avoir 2 membres : data.redirect y data.form . J'ai trouvé cette approche bien meilleure.

Answer 2

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 au ajaxSuccess et vérifie si l'en-tête existe :

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

Answer 3

Aucun navigateur ne gère correctement les réponses 301 et 302. En fait, la norme stipule même qu'ils doivent les traiter "de manière transparente", ce qui est un énorme casse-tête pour les fournisseurs de bibliothèques Ajax. Sur Ra-Ajax nous avons été contraints d'utiliser le code de statut de réponse HTTP 278 (juste un code de succès "inutilisé") pour gérer les redirections transparentes du serveur...

Cela m'ennuie vraiment, et si quelqu'un ici a un peu d'influence sur le W3C, j'apprécierais que vous fassiez savoir au W3C que vous êtes en train d'utiliser le système de gestion de l'information. connaître que nous devons vraiment gérer les codes 301 et 302 nous-mêmes... ;)

Answer 4

La solution finalement mise en œuvre a consisté à utiliser un wrapper pour la fonction de rappel de l'appel Ajax et à vérifier dans ce wrapper l'existence d'un élément spécifique dans le fragment HTML renvoyé. Si l'élément est trouvé, le wrapper exécute une redirection. Sinon, le wrapper transmet 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 ont toujours renvoyé du HTML à l'intérieur d'un élément DIV que nous utilisons pour remplacer un morceau de la page. De plus, nous avions seulement besoin de rediriger vers la page de connexion.

Answer 5

J'aime la méthode de Timmerz avec un léger zeste de citron. Si jamais tu es renvoyé contentType de texte/html quand vous attendez JSON vous êtes 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 le statut de 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 (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();
    }

});