Sair: GET ou POST?

Esta questão não é sobre quando usar GET ou POST em geral; é sobre qual é o recomendado para lidar com o logoff de um aplicativo da web. Encontrei muitas informações sobre as diferenças entre GET e POST no sentido geral, mas não encontrei uma resposta definitiva para esse cenário em particular.

Como pragmático, estou inclinado a usar o GET, porque implementá-lo é muito mais simples que o POST; basta soltar um link simples e pronto. Esse parece ser o caso da grande maioria dos sites em que consigo pensar, pelo menos do alto da minha cabeça. Até o Stack Overflow lida com o logout com GET.

O que me fez hesitar é o argumento (embora antigo) de que alguns aceleradores / proxies da Web pré-armazenam em cache as páginas acessando e recuperando todos os links encontrados na página, para que o usuário obtenha uma resposta mais rápida ao clicar nelas. Não tenho certeza se isso ainda se aplica, mas, se esse fosse o caso, em teoria, um usuário com um desses aceleradores seria expulso do aplicativo assim que efetuar o login, porque o acelerador encontraria e recuperaria o logout mesmo que ela nunca tenha clicado nele.

Tudo o que li até agora sugere que o POST deve ser usado para "ações destrutivas", enquanto as ações que não alteram o estado interno da consulta do aplicativo - como essas - devem ser tratadas com GET . Com base nisso, a verdadeira questão aqui é:

O logoff de um aplicativo é considerado uma ação destrutiva / altera o estado interno do aplicativo?

Use POST.

Em 2010, o uso GETfoi provavelmente uma resposta aceitável. Mas hoje (em 2013), os navegadores buscarão previamente as páginas que eles "acham" que você visitará a seguir.

Aqui está um dos desenvolvedores do StackOverflow falando sobre esse problema no twitter:

Gostaria de agradecer ao meu banco por fazer o logoff de uma solicitação GET e à equipe do Chrome pela pré-busca prática de URLs. - Nick Craver ( @Nick_Craver ) 29 de janeiro de 2013

Curiosidade: StackOverflow costumava lidar com o logout via GET, mas não mais.

No REST, não deve haver sessão; portanto, não há nada para destruir. Um cliente REST é autenticado em cada solicitação. Entrar ou sair, é apenas uma ilusão.

O que você realmente está perguntando é se o navegador deve continuar enviando as informações de autenticação em cada solicitação.

Indiscutivelmente, se o seu aplicativo criar a ilusão de estar logado, você poderá "sair" usando javascript. Não é necessário ida e volta.

Dissertação de Campo - Seção 5.1.3

cada solicitação do cliente para o servidor deve conter todas as informações necessárias para entender a solicitação e não pode tirar proveito de nenhum contexto armazenado no servidor. O estado da sessão é, portanto, mantido inteiramente no cliente

Uma maneira de GETser abusada aqui é que uma pessoa (concorrente talvez :) colocou uma tag de imagem com src="<your logout link>"QUALQUER LUGAR na Internet e, se um usuário do seu site topar com essa página, ele será desconectado.

Para ser correto, GET / POST (ou outros verbos) são ações em algum recurso (endereçado por URL) - portanto, geralmente trata-se do estado do recurso e não do estado do aplicativo como tal. Portanto, com espírito de verdade, você deve ter um URL como [host name]\[user name]\session, 'DELETE' seria o verbo correto para a ação de logout.

Usar [host name]\bla bla\logoutcomo URL não é realmente um caminho completo REST (IMO), então por que debater sobre o uso correto de GET / POST nele?

Obviamente, eu também uso GET em um URL de logout em meus aplicativos :-)

O logout não faz nada para o próprio aplicativo. Ele altera o estado do usuário em relação ao aplicativo. Nesse caso, parece que sua pergunta é mais baseada em como o comando deve ser iniciado pelo usuário para iniciar esta ação. Como essa não é uma "ação destrutiva", verifique se a sessão foi abandonada ou destruída, mas que nem seu aplicativo nem seus dados foram alterados, não é inviável permitir que ambos os métodos iniciem um procedimento de logoff. A postagem deve ser usada por qualquer ação iniciada pelo usuário (por exemplo - o usuário clica em "Logout"), enquanto o get pode ser reservado para logouts iniciados pelo aplicativo (por exemplo - uma exceção que detecta uma possível invasão do usuário forçosamente redireciona para a página de login com um logout GET )

Olá, do meu ponto de vista, ao fazer login, verifique o nome de usuário / senha e, se houver algum, crie o token de login.

Token CREAT => método POST

Quando você está desconectando, distribui o token, portanto, para mim, o método mais lógico deve ser um DELETE

Token DELETE => método DELETE

O cenário de pré-cache é interessante. Mas suponho que, se muitos sites inc SO, não se preocupem com isso, talvez você também não deva.

Ou talvez o link possa ser implementado em javascript?

Edit: Pelo que entendi, tecnicamente um GET deve ser para solicitações somente leitura, que não alteram o estado do aplicativo. Um POST deve ser para solicitações de gravação / edição que mudam de estado. No entanto, outros problemas de aplicativos podem preferir GET sobre POST para algumas solicitações de alteração de estado, e eu não acho que haja algum problema com isso.

Bem, se você deixar seu aplicativo Web abandonar a sessão por meio de um script de logoff, geralmente não será necessário. Normalmente, há uma variável de sessão exclusiva para a sessão que você deseja abandonar.

Recentemente, eu estava trabalhando em um projeto que uso GET para sair. Abaixo está o código no Nodejs Express e funciona perfeitamente bem

seu router.js

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

seu 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'});   
        };

Não vejo como fazer logoff (removendo as permissões de usuário) é uma ação destrutiva. Isso ocorre porque a ação "logout" deve estar disponível apenas para usuários que já estão conectados, caso contrário, seria obsoleta.

Uma sequência gerada aleatoriamente contida nos cookies do navegador está representando a sua sessão do usuário. Existem várias maneiras de destruí-lo de forma tão eficaz. O logout é apenas um serviço para o visitante.