Zastrzeżenie: Jestem nowy w szkole myślenia REST i staram się to ogarnąć.
Tak więc czytam tę stronę, Częste błędy REST i stwierdziłem, że jestem całkowicie zaskoczony tym, że sekcja dotycząca sesji jest nieistotna. Oto, co mówi strona:
Klient nie powinien się „logować” ani „uruchamiać połączenia”. Uwierzytelnianie HTTP odbywa się automatycznie dla każdej wiadomości. Aplikacje klienckie są konsumentami zasobów, a nie usług. Dlatego nie ma się do czego logować! Powiedzmy, że rezerwujesz lot w serwisie internetowym REST. Nie tworzysz nowego połączenia „sesji” z usługą. Zamiast tego należy poprosić „obiekt kreatora trasy” o utworzenie nowego planu podróży. Możesz zacząć wypełniać puste miejsca, ale potem pobierz zupełnie inny komponent z innego miejsca w sieci, aby wypełnić inne puste miejsca. Nie ma sesji, więc nie ma problemu z migracją stanu sesji między klientami. Nie ma również problemu z „koligacją sesji”
OK, rozumiem, że uwierzytelnianie HTTP jest wykonywane automatycznie dla każdej wiadomości - ale jak? Czy nazwa użytkownika / hasło są wysyłane z każdym żądaniem? Czy to nie tylko zwiększa powierzchnię ataku? Czuję, że brakuje mi części układanki.
Czy nie byłoby źle mieć, powiedzmy, usługę REST /session, która akceptuje żądanie GET, w której podałbyś nazwę użytkownika / hasło jako część żądania i zwraca token sesji, jeśli uwierzytelnianie się powiodło, to może być wtedy przekazane wraz z kolejnymi wnioskami? Czy to ma sens z punktu widzenia REST, czy to nie ma sensu?
Odpowiedzi:
Aby było zgodne z REST, każde żądanie HTTP powinno samo w sobie zawierać wystarczającą ilość informacji, aby jego odbiorca mógł je przetworzyć, aby było w pełnej harmonii z bezstanowym charakterem protokołu HTTP.
Tak, nazwa użytkownika i hasło są wysyłane z każdym żądaniem. Typowe metody to uwierzytelnianie dostępu podstawowego i uwierzytelnianie dostępu skróconego . I tak, podsłuchiwacz może przechwycić dane uwierzytelniające użytkownika. W ten sposób można by szyfrować wszystkie dane wysyłane i odbierane przy użyciu protokołu Transport Layer Security (TLS) .
Nie byłoby to RESTful, ponieważ przenosi stan, ale jest jednak dość powszechne, ponieważ jest to wygoda dla użytkowników; użytkownik nie musi się każdorazowo logować.
To, co opisujesz w „tokenie sesji”, jest powszechnie określane jako plik cookie logowania . Na przykład, jeśli spróbujesz zalogować się do swojego konta Yahoo! na koncie jest pole wyboru z napisem „Nie wylogowuj mnie przez 2 tygodnie”. Zasadniczo oznacza to (w twoich słowach) „zachowaj mój token sesji przez 2 tygodnie, jeśli się pomyślnie zaloguję”. Przeglądarki internetowe będą wysyłać takie pliki cookie logowania (i być może inne) z każdym żądaniem HTTP, o które poprosisz.
źródło
Często zdarza się, że usługa REST wymaga uwierzytelniania dla każdego żądania HTTP. Na przykład Amazon S3 wymaga, aby każde żądanie miało podpis pochodzący z poświadczeń użytkownika, dokładnego żądania do wykonania i aktualnego czasu. Podpis ten jest łatwy do obliczenia po stronie klienta, może być szybko zweryfikowany przez serwer i ma ograniczone zastosowanie dla atakującego, który go przechwyci (ponieważ jest oparty na aktualnym czasie).
źródło
Wiele osób nie rozumie zasad REST bardzo jasno, używanie tokena sesji nie oznacza, że zawsze jesteś stanowy, powodem wysyłania nazwy użytkownika / hasła przy każdym żądaniu jest tylko uwierzytelnienie i to samo przy wysyłaniu tokena (generowanego przez logowanie procesu) tylko po to, aby zdecydować, czy klient ma pozwolenie na żądanie danych, czy nie, naruszasz konwersję REST tylko wtedy, gdy używasz nazwy użytkownika / hasła lub tokenów sesji, aby zdecydować, jakie dane pokazać! zamiast tego musisz ich używać tylko do uwierzytelniania (aby pokazać dane lub nie pokazać danych)
w twoim przypadku mówię TAK, to jest RESTy, ale staraj się unikać natywnych sesji php w swoim REST API i zacznij generować własne zaszyfrowane tokeny, które wygasają w określonym czasie!
źródło
Nie, to nie mija się z celem. Google ClientLogin działa dokładnie w ten sposób, z godnym uwagi wyjątkiem, że klient otrzymuje polecenie przejścia do „/ session” za pomocą odpowiedzi HTTP 401. Ale to nie tworzy sesji, a jedynie stwarza klientom możliwość (tymczasowego) uwierzytelnienia się bez przekazywania poświadczeń w trybie Clear, a serwerowi kontrolę ważności tych tymczasowych poświadczeń według własnego uznania.
źródło
„Autoryzacja”: nagłówek HTTP wysłany przez klienta. Podstawowy (zwykły tekst) lub skrót.
Cała idea sesji polega na tworzeniu aplikacji stanowych przy użyciu protokołu bezstanowego (HTTP) i głupiego klienta (przeglądarki internetowej), utrzymując stan po stronie serwera. Jedną z zasad REST jest „Każdy zasób jest jednoznacznie adresowalny przy użyciu uniwersalnej składni do użytku w linkach hipermedialnych” . Zmienne sesji to coś, do czego nie można uzyskać dostępu za pośrednictwem identyfikatora URI. Prawdziwie RESTful aplikacja utrzymywałaby stan po stronie klienta, wysyłając wszystkie niezbędne zmienne przez HTTP, najlepiej w URI.
Przykład: wyszukiwanie z paginacją. Miałbyś adres URL w formularzu
Ma to wiele wspólnego z adresami URL objętymi zakładkami
źródło
Myślę, że twoja sugestia jest OK, jeśli chcesz kontrolować czas życia sesji klienta. Myślę, że architektura RESTful zachęca do tworzenia aplikacji bezstanowych. Jak napisał @ 2pence, „każde żądanie HTTP powinno samo w sobie zawierać wystarczającą ilość informacji, aby jego odbiorca mógł je przetworzyć, aby było w pełnej harmonii z bezstanowym charakterem HTTP” .
Jednak nie zawsze tak jest, czasami aplikacja musi informować, kiedy klient loguje się lub wylogowuje i na podstawie tych informacji utrzymywać zasoby, takie jak blokady lub licencje. Przykład takiej sprawy można znaleźć w moim pytaniu uzupełniającym .
źródło