Logout: OTTIENI o POST?

Questa domanda non riguarda quando utilizzare GET o POST in generale; si tratta di quale è quella consigliata per la gestione della disconnessione da un'applicazione web. Ho trovato molte informazioni sulle differenze tra GET e POST in senso generale, ma non ho trovato una risposta definitiva per questo particolare scenario.

Come pragmatico, sono propenso a usare GET, perché implementarlo è molto più semplice di POST; rilascia un semplice link e il gioco è fatto. Questo sembra essere il caso della stragrande maggioranza dei siti Web a cui riesco a pensare, almeno dalla cima della mia testa. Anche Stack Overflow gestisce la disconnessione con GET.

La cosa che mi fa esitare è l'argomentazione (sebbene vecchia) secondo cui alcuni acceleratori / proxy web pre-memorizzano le pagine andando e recuperando tutti i collegamenti che trovano nella pagina, in modo che l'utente ottenga una risposta più veloce quando fa clic su di essi. Non sono sicuro che ciò si applichi ancora, ma se fosse così, in teoria un utente con uno di questi acceleratori verrebbe espulso dall'applicazione non appena accedeva, perché il suo acceleratore avrebbe trovato e recuperato il logout link anche se non ci ha mai cliccato sopra.

Tutto ciò che ho letto finora suggerisce che il POST dovrebbe essere usato per "azioni distruttive", mentre le azioni che non alterano lo stato interno dell'applicazione - interrogazioni simili e simili - dovrebbero essere gestite con GET . Sulla base di questo, la vera domanda qui è:

La disconnessione da un'applicazione è considerata un'azione distruttiva / modifica lo stato interno dell'applicazione?

Usa POST.

Nel 2010, l'utilizzo GETera probabilmente una risposta accettabile. Ma oggi (nel 2013), i browser pre-recupereranno le pagine che "pensano" che visiterai in seguito.

Ecco uno degli sviluppatori StackOverflow che parla di questo problema su Twitter:

Vorrei ringraziare la mia banca per aver effettuato la disconnessione da una richiesta GET e il team di Chrome per il comodo prefetching dell'URL. - Nick Craver ( @Nick_Craver ) 29 gennaio 2013

fatto curioso: StackOverflow usato per gestire il log-out tramite GET, ma non più.

In REST non ci dovrebbero essere sessioni, quindi non c'è nulla da distruggere. Un client REST si autentica su ogni richiesta. Connesso o disconnesso, è solo un'illusione.

Quello che stai veramente chiedendo è se il browser continua a inviare le informazioni di autenticazione su ogni richiesta.

Probabilmente, se la tua applicazione crea l'illusione di essere loggato, dovresti essere in grado di "disconnetterti" usando javascript. Nessun viaggio di andata e ritorno richiesto.

Tesi di fielding - Sezione 5.1.3

ogni richiesta dal client al server deve contenere tutte le informazioni necessarie per comprendere la richiesta e non può sfruttare alcun contesto memorizzato sul server. Lo stato della sessione viene quindi mantenuto interamente sul client

Un modo GETpotrebbe essere abusato qui è che una persona (forse un concorrente :) ha inserito un tag immagine con src="<your logout link>"OVUNQUE su Internet e se un utente del tuo sito si imbatte in quella pagina, verrà disconnesso inconsapevolmente.

Per essere corretti, GET / POST (o altri verbi) sono azioni su alcune risorse (indirizzate dall'URL), quindi generalmente riguardano lo stato della risorsa e non lo stato dell'applicazione in quanto tale. Quindi, nel vero spirito, dovresti avere un URL come [host name]\[user name]\session, quindi 'ELIMINA' sarebbe il verbo corretto per l'azione di disconnessione.

Utilizzando [host name]\bla bla\logoutcome URL in realtà non un REST full way (IMO), quindi perché discutere sul corretto uso di GET / POST su di esso?

Naturalmente, utilizzo anche GET per un URL di logout nelle mie applicazioni :-)

La disconnessione non fa nulla per l'applicazione stessa. Cambia lo stato dell'utente in relazione all'applicazione. In questo caso, sembra che la tua domanda sia più basata sul modo in cui il comando deve essere avviato dall'utente per iniziare questa azione. Poiché questa non è "un'azione distruttiva", è certo che la sessione sia stata abbandonata o distrutta ma che né l'applicazione né i dati siano stati modificati, non è possibile consentire ad entrambi i metodi di avviare una procedura di disconnessione. Il post deve essere utilizzato da tutte le azioni avviate dall'utente (ad es. - l'utente fa clic su "Esci"), mentre get potrebbe essere riservato per le disconnessioni avviate dall'applicazione (ad esempio - un'eccezione che rileva la potenziale intrusione dell'utente reindirizza forzatamente alla pagina di accesso con una disconnessione GET ).

Ciao dal mio punto di vista, quando accedi controlla nome utente / password e se quelli sono corrispondenti crei il token di accesso.

Token CREAT => metodo POST

Quando esci, devi distribuire il token, quindi per me il metodo più logico dovrebbe essere un DELETE

Token DELETE => metodo DELETE

Lo scenario di pre-cache è interessante. Ma suppongo che se molti siti, tra cui SO, non si preoccupano di questo, forse non dovresti farlo neanche tu.

O forse il link potrebbe essere implementato in javascript?

Modifica: a quanto ho capito, tecnicamente un GET dovrebbe essere per le richieste di sola lettura, che non cambiano lo stato dell'applicazione. Un POST dovrebbe essere per le richieste di scrittura / modifica che cambiano stato. Tuttavia, altri problemi relativi all'applicazione potrebbero preferire GET rispetto a POST per alcune richieste che cambiano stato e non credo che ci siano problemi.

Bene, se lasci che la tua applicazione web lasci la sessione attraverso uno script di logout, di solito non ti serve neanche. Normalmente esiste una variabile di sessione unica per la sessione che si desidera abbandonare.

Recentemente stavo lavorando a un progetto che utilizzo GET per disconnettersi Di seguito è riportato il codice in Nodejs Express e funziona perfettamente

il tuo router.js

const express = require("express");
router.get("/signout", signout);

controller.js

exports.signout  = (req, res) => {
        res.clearCookie('t'); //clearing cookie, which is 
            //assign to the user during sign in.          
            res.json({message : 'Signout success'});   
        };

Non vedo come disconnettersi (deselezionare le autorizzazioni utente) sia un'azione descrittiva. Questo perché l'azione "disconnessione" dovrebbe essere disponibile solo per gli utenti che hanno già effettuato l'accesso altrimenti sarebbe obsoleta.

Una stringa generata in modo casuale contenuta nei cookie del browser rappresenta tutti la sessione dell'utente. Esistono molti modi per distruggerlo, quindi la disconnessione in modo efficace è semplicemente un servizio per il tuo visitatore.