Wyloguj się: GET czy POST?

To pytanie nie dotyczy tego, kiedy ogólnie używać GET lub POST; dotyczy tego, który jest zalecany do obsługi wylogowania z aplikacji internetowej. Znalazłem wiele informacji na temat różnic między GET i POST w sensie ogólnym, ale nie znalazłem jednoznacznej odpowiedzi dla tego konkretnego scenariusza.

Jako pragmatyk mam skłonność do używania GET, ponieważ jego implementacja jest znacznie prostsza niż POST; po prostu upuść prosty link i gotowe. Wydaje się, że tak jest w przypadku większości stron internetowych, o których mogę myśleć, przynajmniej z góry mojej głowy. Nawet przepełnienie stosu obsługuje wylogowanie za pomocą GET.

Waham się z (choć starym) argumentem, że niektóre akceleratory internetowe / serwery proxy wstępnie buforują strony, przechodząc i pobierając każdy link, który znajdują na stronie, więc użytkownik otrzymuje szybszą odpowiedź, gdy je kliknie. Nie jestem pewien, czy nadal tak jest, ale jeśli tak, to teoretycznie użytkownik z jednym z tych akceleratorów zostanie wyrzucony z aplikacji, gdy tylko się zaloguje, ponieważ jej akcelerator znajdzie i wyloguje się link, nawet jeśli nigdy go nie kliknęła.

Wszystko, co przeczytałem do tej pory, sugeruje, że POST powinien być używany do „działań destrukcyjnych”, podczas gdy działania, które nie zmieniają wewnętrznego stanu zapytań podobnych do aplikacji i takie powinny być obsługiwane za pomocą GET . Na tej podstawie prawdziwe pytanie brzmi:

Czy wylogowanie z aplikacji jest uważane za działanie destrukcyjne / czy zmienia wewnętrzny stan aplikacji?

Zastosowanie POST.

W 2010 r. Używanie GETbyło prawdopodobnie akceptowalną odpowiedzią. Ale dzisiaj (w 2013 r.) Przeglądarki pobierają strony, które „myślą”, że odwiedzą w następnej kolejności.

Oto jeden z programistów StackOverflow mówiący o tym problemie na Twitterze:

Chciałbym podziękować mojemu bankowi za wylogowanie się z żądania GET, a zespołowi Chrome za przydatne wstępne pobieranie adresów URL. - Nick Craver ( @Nick_Craver ) 29 stycznia 2013

fajny fakt: StackOverflow służy do obsługi wylogowania za pomocą GET, ale już nie.

W REST nie powinno być sesji, dlatego nie ma nic do zniszczenia. Klient REST uwierzytelnia się na każde żądanie. Zalogowany lub wylogowany, to tylko złudzenie.

Naprawdę pytasz, czy przeglądarka będzie nadal wysyłać informacje uwierzytelniające przy każdym żądaniu.

Prawdopodobnie, jeśli twoja aplikacja wywołuje złudzenie bycia zalogowanym, powinieneś być w stanie „wylogować się” za pomocą javascript. Nie jest wymagana podróż w obie strony.

Rozprawa polowa - sekcja 5.1.3

każde żądanie od klienta do serwera musi zawierać wszystkie informacje niezbędne do zrozumienia żądania i nie może korzystać z żadnego kontekstu przechowywanego na serwerze. Stan sesji jest zatem w całości przechowywany na kliencie

Jednym ze sposobów GETmoże być nadużycie w tym miejscu, że osoba (być może konkurent :) umieściła tag internetowy z src="<your logout link>"KAŻDYM w Internecie, a jeśli użytkownik Twojej witryny natknie się na tę stronę, zostanie nieświadomie wylogowany.

Aby być poprawnym, GET / POST (lub inne czasowniki) są działaniami na pewnym zasobie (adresowanym przez URL) - więc ogólnie dotyczy stanu zasobu, a nie stanu aplikacji jako takiego. Tak więc w prawdziwych nastrojach powinieneś mieć taki adres URL, jak [host name]\[user name]\session„DELETE” byłby właściwym czasownikiem dla akcji wylogowania.

Używanie [host name]\bla bla\logoutjako adresu URL w rzeczywistości nie jest w pełni REST (IMO), więc po co debata na temat poprawnego użycia GET / POST na nim?

Oczywiście używam GET do wylogowania adresu URL w moich aplikacjach :-)

Wylogowanie nie ma wpływu na samą aplikację. Zmienia stan użytkownika w stosunku do aplikacji. W tym przypadku wydaje się, że twoje pytanie jest bardziej oparte na tym, jak użytkownik powinien zainicjować polecenie, aby rozpocząć tę akcję. Ponieważ nie jest to „działanie destrukcyjne”, sesja zostanie porzucona lub zniszczona, ale ani aplikacja, ani dane nie zostaną zmienione, zezwolenie obu metodom na zainicjowanie procedury wylogowania jest niemożliwe. Post powinien być wykorzystywany przez wszelkie działania inicjowane przez użytkownika (np. - użytkownik klika „Wyloguj się”), podczas gdy get może być zarezerwowany na wylogowanie inicjowane przez aplikację (np. - wyjątek wykrywający potencjalną ingerencję użytkownika wymusza przekierowanie na stronę logowania przy wylogowaniu GET ).

Witam z mojego punktu widzenia, kiedy logujesz się, sprawdzasz nazwę użytkownika / hasło i jeśli są one zgodne, tworzysz token logowania.

UTWÓRZ token => metoda POST

Kiedy się wylogowujesz, odwracasz tokena, więc dla mnie najbardziej logiczną metodą powinno być USUŃ

DELETE token => metoda DELETE

Scenariusz buforowania wstępnego jest interesujący. Ale zgaduję, że jeśli wiele witryn i tak NIE martw się o to, to może nie powinieneś.

A może link może być zaimplementowany w javascript?

Edycja: Jak rozumiem, technicznie GET powinien być dla żądań tylko do odczytu, które nie zmieniają stanu aplikacji. POST powinien dotyczyć żądań zapisu / edycji, które zmieniają stan. Jednak inne problemy z aplikacjami mogą preferować GET zamiast POST w przypadku niektórych żądań zmieniających stan, i nie sądzę, aby był z tym problem.

Cóż, jeśli pozwolisz aplikacji internetowej zrezygnować z sesji za pomocą skryptu wylogowania, zwykle też nie potrzebujesz. Zwykle istnieje zmienna sesji, która jest unikalna dla sesji, którą chcesz porzucić.

Ostatnio pracowałem nad projektem, którego używam GET do wylogowania Poniżej znajduje się kod w Nodejs Express i działa on doskonale

twój router.js

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

twoja kontroler.js

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

Nie rozumiem, jak wylogowanie (cofnięcie uprawnień użytkownika) jest działaniem dezintegrującym. Jest tak, ponieważ akcja „wylogowania” powinna być dostępna tylko dla użytkowników, którzy są już zalogowani, w przeciwnym razie byłaby przestarzała.

Losowo generowany ciąg znaków zawarty w ciasteczkach przeglądarki oznacza sesję użytkownika. Istnieje wiele sposobów na zniszczenie go, więc skuteczne wylogowanie jest jedynie usługą dla odwiedzających.