come devo gestire l'errore del server durante il logout di ajax?

4

Devo scrivere un gestore per l'errore del server durante la disconnessione dell'utente. Cos'è una pratica comune?

ajax.post({
    url: '/auth/logout'
}).done(function (response) {
    switch (response.statusCode) {
        case 200:
        {
            //update UI related to userinformation
        }
        case 500:
        {
            //what should I do here?
        }
    }
})

Nota: la funzione Ajax è la reimplementazione di $ .ajax () con l'eccezione che richiama sempre il callback (l'oggetto promessa personalizzato è sempre risolto e mai rifiutato)

UPDATE: Sul server distruggo la sessione ed elimini il cookie di accesso automatico se è presente. È un approccio ragionevole (se viene ricevuto un errore del server) cancellare i cookie relativi al nome della sessione e al login automatico sul client usando javascript (presumendo che conosca il loro nome)?

    
posta Max Koretskyi aka Wizard 19.03.2014 - 20:35
fonte

3 risposte

2

Fondamentalmente dovresti fare la stessa cosa che hai fatto per il successo: fai sapere all'utente.

Si noti che questo è specifico per il front-end, perché la sessione front-end continua. Il back-end dovrebbe restituire il successo, anche se non ha una sessione valida da chiudere. Solo se è veramente, per qualche strana ragione, andando a mantenere la sessione, dovrebbe restituire un fallimento. In tal caso è fondamentale che il front end ne informi l'utente.

    
risposta data 19.03.2014 - 21:41
fonte
2

Quando si verifica un errore in un'applicazione Web, questo è ciò che accade:

  1. Errore
  2. Try / Catch (o qualsiasi altro meccanismo di comparazione)
  3. window.error
  4. Errore del browser

La tua applicazione dovrebbe considerare 2 tipi di errori (minimo):

  1. Errore FATAL
  2. Errore NON FATALE

Un errore fatale è un errore che non consente l'esecuzione dell'applicazione e non considera la possibilità che il client torni ad eseguire l'azione. Probabilmente, l'utente viene informato che si è verificato un errore e tutte le informazioni già presenti nel client vengono distrutte per forzare una creazione della struttura dati necessaria da zero.

Un errore NON fatale deve consentire all'utente di capire che qualcosa è successo e, nel caso di log-in, lui / lei / lei deve rieseguire il azione.

Quindi, come descritto:

Un 500 dal server non può essere considerato un errore fatale in un'app Web per l'azione di accesso. Dovrebbe essere trattato come un'azione come gli altri, probabilmente NON fatale .

Una buona pratica per capire quali errori considerare e qual è il loro grado di gravità, è creare una tabella che descriva le azioni e considerare le colonne con le diverse opzioni di possibili errori:

a. url non valido;

b. errore di risposta del server;

c. errore del contenuto della risposta;

d. connessione fisica / errori di rete;

    
risposta data 19.03.2014 - 21:16
fonte
2

Questo è legato alla vecchia domanda, "Come gestisco l'errore se provo a eliminare una risorsa che non è stata trovata?" In pratica, il lavoro è finito. Di solito, mi limito ad andare avanti, al massimo loggando un WARN se è importante.

Il rischio qui deriva dal fatto che una sessione di accesso è un artefatto di sicurezza. Quindi se il logout fallisce, potresti avere una sessione persistente che sarebbe vulnerabile ad attacchi.

La maggior parte delle volte potrebbe non avere importanza. Generalmente, una volta rilasciato il riferimento al token di sessione (o qualsiasi altro artefatto di sicurezza che stai utilizzando), non può essere comunque ripristinato.

A seconda dell'esperienza utente che desideri, potresti semplicemente fallire silenziosamente, oppure far sapere all'utente che quel logout è fallito, e lasciare che provino di nuovo.

Ma se stavi scrivendo un sito web per una banca, è più un problema. Implementare una sorta di meccanismo dei tentativi. Magari eseguirlo in background, per riprovare fino a ottenere un risultato positivo.

    
risposta data 19.03.2014 - 20:54
fonte

Leggi altre domande sui tag