Come impedire alle richieste ajax di seguire i reindirizzamenti utilizzando jQuery

Uso le funzioni jQuery ajax per accedere a un servizio web, ma il server, invece di restituire una risposta con un codice di stato che descrive un problema, la richiesta viene reindirizzata a una pagina con un'intestazione 200, che descrive il problema. Non posso apportare modifiche a questo, quindi devo risolverlo in qualche modo sul client.

Esempio: una richiesta va a un URL che non viene trovato, quindi ricevo un reindirizzamento 302 a un'altra posizione. Viene inviata una nuova richiesta e ricevo 200 OK, impedendo così l'attivazione della richiamata di errore.

C'è un modo per impedire alla richiesta ajax di seguire i reindirizzamenti e invocare invece un callback, preferibilmente il metodo di errore. In alternativa, è possibile rilevare se si è verificato un reindirizzamento nel client?

Trovo la tua domanda interessante, ma il problema nel complesso mi sembra più un malinteso. Almeno cercherò di spiegare la mia comprensione del problema.

Il reindirizzamento silenzioso (trasparente) è la parte delle XMLHttpRequestspecifiche (vedere qui in particolare le parole "... seguire in modo trasparente il reindirizzamento ..."). Lo standard menziona solo che l'agente utente (il browser web) può impedire o notificare certi tipi di reindirizzamenti automatici, ma non fa parte di XMLHttpRequest. Fa parte della configurazione del client HTTP (configurazione del sistema operativo) o della configurazione del browser web. Quindi jQuery.ajaxnon puoi avere alcuna opzione in cui puoi impedire il reindirizzamento.

Puoi vedere che il reindirizzamento HTTP fa parte del protocollo HTTP e non fa parte di XMLHttpRequest. Quindi è su un altro livello di astrazione o sullo stack di rete. Ad esempio, i dati da XMLHttpRequestpossono essere recuperati dal proxy HTTP o dalla cache del browser locale, ed è la parte del protocollo HTTP. Per lo più il server che fornisce i dati e non il client può influenzare il caching.

È possibile confrontare il requisito della domanda con il requisito per impedire la modifica dell'indirizzo IP del server Web o la modifica del percorso IP durante la comunicazione. Tutte le cose possono essere interessanti in alcuni scenari, ma ci sono parti di un altro livello dello stack di comunicazione e non possono essere gestite da jQuery.ajaxo XMLHttpRequest.

Lo XMLHttpRequeststandard dice che la configurazione del client può avere opzioni che impediscono il reindirizzamento. In caso di "mondo Microsoft", che conosco meglio, puoi guardare la funzione WinHttpSetOption che può essere utilizzata per impostare l' WINHTTP_OPTION_DISABLE_FEATUREopzione con il WINHTTP_DISABLE_REDIRECTSvalore. Un altro modo è l'utilizzo WINHTTP_OPTION_REDIRECT_POLICYdell'opzione con il WINHTTP_OPTION_REDIRECT_POLICY_NEVERvalore. Un'altra caratteristica che è possibile utilizzare in Windows è la funzione WinHttpSetStatusCallback che può impostare la funzione di callback ricevuta da alcune notifiche come WINHTTP_CALLBACK_FLAG_REDIRECT.

Quindi è possibile implementare i tuoi requisiti in generale, ma la soluzione probabilmente non sarà indipendente dal sistema operativo o dal browser web e non sarà al livello di jQuery.ajaxo XMLHttpRequest.

Non credo sia possibile. La libreria sottostante (XHR) effettua la nuova richiesta in modo trasparente. Detto questo, quello che ho fatto in queste situazioni (di solito un tipo di contratto di timeout della sessione che mi porta a una pagina di accesso) è stato restituito un'intestazione di risposta personalizzata. Ho anche configurato un gestore Ajax globale che controlla la presenza di tale intestazione e risponde in modo appropriato quando presente (ad esempio, reindirizzando l'intera pagina alla schermata di accesso).

Nel caso tu sia interessato, ecco il codice jQuery che devo guardare per quell'intestazione personalizzata:

/* 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)

Ho trovato una funzione per verificare se la tua chiamata è stata reindirizzata. È xhr.state (): se è "rifiutato", si è verificato un reindirizzamento.

Esempio con callback di successo:

request.success(function(data, textStatus, xhr)
{
    if(xhr.state() == "resolved")
    {
        //no redirection
    }
    if(xhr.state() == "rejected")
    {
        //redirection
    }
});

Esempio con callback di errore:

request.error(function(xhr, textStatus)
{
    if (xhr.state() == "rejected")
    {
        //redirection
        location.href = "loginpage";
    } else
    {
        //some other error happened
        alert("error");
    }
});

Non posso aggiungere alla saggezza perspicace dei precedenti programmatori che hanno risposto, ma aggiungerò un caso specifico che altri potrebbero trovare utile sapere.

Mi sono imbattuto in questo reindirizzamento silenzioso 302 nel contesto di SharePoint. Ho un semplice codice client Javascript che esegue il ping di un sito secondario di SharePoint e, se riceve una risposta HTTP 200, si trasferisce a quel sito, tramite window.location. Se riceve qualcos'altro, avvisa l'utente che il sito non esiste.

Tuttavia, nel caso in cui il sito esista ma l'utente non dispone dell'autorizzazione, SharePoint reindirizza automaticamente a una pagina AccessDenied.aspx. SharePoint ha già eseguito l'handshake dell'autenticazione HTTP 401 a livello di server / farm: l'utente ha accesso a SharePoint. Ma l'accesso al sito secondario è gestito suppongo utilizzando flag di database di qualche tipo. Il reindirizzamento silenzioso ignora la mia clausola "else", quindi non posso sollevare il mio errore. Nel mio caso, questo non è un ostacolo allo spettacolo: è un comportamento prevedibile coerente. Ma è stato un po 'sorprendente e ho imparato qualcosa sulle richieste HTTP nel processo!

Ero interessato alla stessa cosa e non sono riuscito a trovare il state()metodo menzionato da Takman e ho scavato un po 'da solo. Per il bene delle persone che si presentano qui in cerca di una risposta, ecco i miei risultati:

Come affermato più volte, non è possibile impedire i reindirizzamenti, ma è possibile rilevarli. Secondo MDN è possibile utilizzare il responseURLdel XMLHttpRequestObject, che conterrà l'URL finale da cui proviene la risposta, dopo tutti i reindirizzamenti. L'unico avvertimento è che non è supportato da Internet Explorer (Edge lo ha). Poiché il xhr/ jqXHRpassato nella funzione success/ donedi jquery è un'estensione dell'attuale XMLHttpRequest, dovrebbe essere disponibile anche lì.

Suppongo che tu riceva una risposta 200 perché la seconda volta non c'è reindirizzamento, perché la pagina 404 non scade, viene salvata nella cache. Vale a dire che la seconda volta che il browser ti dà la pagina nella cache. C'è una proprietà "cache" nel jquery ajax. http://api.jquery.com/jQuery.ajax/

Dovresti scriverlo su "false"

Sebbene non sia possibile disabilitare il reindirizzamento della posizione in XmlHttpRequests , lo è quando si utilizza fetch () :

fetch('url', {redirect: manual});

Non sono sicuro che questo si applicherà al tuo caso, ma puoi scrivere codice per rispondere a codici di stato specifici nella funzione AJAX -

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

Nelle intestazioni della richiesta nel caso di una richiesta ajax avrai quanto segue

X-Requested-With    XMLHttpRequest

Con questo criterio sul lato server puoi filtrare le richieste.