Czy sesje naprawdę naruszają spokój?

Po pierwsze, odpoczynek nie jest religią i nie powinien być traktowany jako taki. Chociaż istnieją zalety usług odpoczynku, powinieneś przestrzegać zasad odpoczynku tylko w zakresie, w jakim mają one sens dla Twojej aplikacji.

To powiedziawszy, uwierzytelnianie i stan po stronie klienta nie naruszają zasad REST. Podczas gdy REST wymaga, aby przejścia stanu były bezstanowe, odnosi się to do samego serwera. W sercu cały odpoczynek to dokumenty. Ideą bezpaństwowości jest to, że serwer jest bezpaństwowy, nie klienci. Każdy klient wysyłający identyczne żądanie (te same nagłówki, pliki cookie, URI itp.) powinien zostać przeniesiony do tego samego miejsca w aplikacji. Jeśli strona internetowa przechowuje bieżącą lokalizację użytkownika i zarządza nawigacją poprzez aktualizację tej zmiennej nawigacyjnej po stronie serwera, reszta zostanie naruszona. Inny klient z identycznymi informacjami o żądaniu zostanie przeniesiony do innej lokalizacji w zależności od stanu po stronie serwera.

Serwisy internetowe Google to fantastyczny przykład systemu RESTful. Wymagają one podania nagłówka uwierzytelniania z kluczem uwierzytelniania użytkownika przy każdym żądaniu. Narusza to nieco zasady REST, ponieważ serwer śledzi stan klucza uwierzytelniania. Stan tego klucza musi być zachowany i ma jakąś datę/godzinę wygaśnięcia, po której nie udziela już dostępu. Jednak, jak wspomniałem na początku mojego postu, należy poświęcić się, aby umożliwić podanie rzeczywiście praca. To powiedziawszy, tokeny uwierzytelniania muszą być przechowywane w sposób, który pozwala wszystkim możliwym klientom kontynuować przyznawanie dostępu w ich ważnych czasach. Jeśli jeden serwer zarządza stanem klucza uwierzytelniania do tego stopnia, że inny serwer z równoważeniem obciążenia nie może przejąć spełniania żądań opartych na tym kluczu, zaczęło to naprawdę naruszać zasady REST. Usługi Google zapewniają, że w każdej chwili możesz wziąć token uwierzytelniania, którego używałeś w telefonie, przeciwko load balance server a i hit load balance server B z pulpitu i nadal mają dostęp do systemu i być kierowane do tych samych zasobów, jeśli żądania były identyczne.

Wszystko sprowadza się do tego, że musisz upewnić się, że tokeny uwierzytelniania są sprawdzane w jakimś magazynie zapasowym (baza danych, Pamięć podręczna, cokolwiek), aby upewnić się, że zachowasz jak najwięcej właściwości REST, jak to możliwe.

Mam nadzieję, że to wszystko miało sens. Należy również sprawdzić sekcja ograniczeń {[10] } artykułu Wikipedii na temat reprezentacji Państwa jeśli jeszcze tego nie zrobiłeś. Jest to szczególnie pouczające w odniesieniu do tego, o co tak naprawdę opowiadają Zasady odpoczynku i dlaczego.

Pliki cookie nie służą do uwierzytelniania. Po co wymyślać koło na nowo? HTTP posiada dobrze zaprojektowane mechanizmy uwierzytelniania. Jeśli używamy plików cookie, wpadamy w używanie HTTP tylko jako protokołu transportowego, dlatego musimy stworzyć nasz własny system sygnalizacji , na przykład, aby powiedzieć użytkownikom, że dostarczyli błędne uwierzytelnianie (użycie HTTP 401 byłoby nieprawidłowe, ponieważ prawdopodobnie nie dostarczylibyśmy Www-Authenticate klientowi, jak wymaga Specyfikacja HTTP :) ). Należy również zauważyć, że Set-Cookie jest jedynie zaleceniem dla klient. Jego zawartość może być lub nie może być zapisana( na przykład, jeśli pliki cookie są wyłączone), podczas gdy nagłówek Authorization jest wysyłany automatycznie na każde żądanie.

Inną kwestią jest to, że aby uzyskać plik cookie autoryzacji, prawdopodobnie będziesz chciał najpierw podać swoje poświadczenia gdzieś? Jeśli tak, to czy nie byłoby to niespokojne? Prosty przykład:

• próbujesz GET /a bez ciasteczek
• otrzymujesz w jakiś sposób prośbę o autoryzację
• idziesz i autoryzujesz jakoś tak jak POST /auth
• dostajesz Set-Cookie
• you try GET /a z ciasteczkiem. Ale czy GET /a zachowuje się w tym przypadku idempotentnie?

Podsumowując, uważam, że jeśli uzyskamy dostęp do jakiegoś zasobu i musimy uwierzytelnić, to musimy uwierzytelnić na tym samym zasobie , a nie gdziekolwiek indziej.

W rzeczywistości RESTfulness odnosi się tylko do zasobów, jak wskazuje Uniwersalny Identyfikator zasobów. Więc nawet mówić o rzeczach takich jak nagłówki, ciasteczka, itp. w odniesieniu do odpoczynku nie jest naprawdę właściwe. REST może działać na dowolnym protokole, nawet jeśli zdarza się, że jest to rutynowo wykonywane przez HTTP.

Głównym wyznacznikiem jest to: jeśli wyślesz wywołanie REST, które jest URI, to gdy wywołanie zakończy się pomyślnie na serwerze, to URI zwróci tę samą zawartość, nie zakładając żadnych przejść zostały wykonane (PUT, POST, DELETE)? Ten test wyklucza zwracanie błędów lub żądań uwierzytelniania, ponieważ w takim przypadku żądanie nie dotarło jeszcze do serwera, co oznacza, że servlet lub aplikacja zwróci dokument odpowiadający podanemu URI.

Podobnie, w przypadku POST lub PUT, możesz wysłać dany URI/payload i niezależnie od tego, ile razy wyślesz wiadomość, zawsze zaktualizuje te same dane, aby kolejne GETs zwróciły konsekwentny wynik?

Reszta dotyczy danych aplikacji, a nie Informacji niskiego poziomu wymaganych do przesłania tych danych.

W poniższym wpisie na blogu Roy Fielding dał miłe podsumowanie całego pomysłu na odpoczynek:

Http://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/5841

" układ RESTful przechodzi z jednego stanu stacjonarnego do następnie, a każdy taki stan stacjonarny jest zarówno potencjalnym stanem początkowym i potencjał stan końcowy. Czyli system RESTful jest nieznanym liczba elementów spełniających prosty zbiór reguł takich, że są zawsze w stanie spoczynku lub przechodzą z jednego odpoczynku stan do innego stanu spoczynku. Każdy stan może być całkowicie rozumiane przez reprezentację(reprezentacje), które zawiera oraz zbiór przejścia, które zapewnia, z przejściami ograniczonymi do jednolity zestaw działań, aby były zrozumiałe. System może być skomplikowany diagram stanu, ale każdy agent użytkownika jest w stanie zobaczyć tylko jeden stan w czasie (obecny stan stacjonarny) , a więc każdy stan jest prosty i może być analizowany niezależnie. Użytkownik OTOH, jest w stanie tworzyć własne przejścia w dowolnym momencie (np. enter adres URL, wybierz zakładkę, otwórz edytor itp.)."

Przechodząc do kwestii uwierzytelniania, niezależnie od tego, czy odbywa się to za pomocą Plików cookie, czy nagłówków, o ile informacje nie są częścią URI i POST payload, tak naprawdę nie ma to nic wspólnego z resztą. Tak więc, w odniesieniu do bycia bezpaństwowcem, mówimy tylko o danych aplikacji.

Na przykład, gdy użytkownik wprowadza dane do ekranu GUI, klient śledzi, które pola zostały wprowadzone, a które nie, wszystkie wymagane pola, których brakuje itp. To wszystko jest kontekstem klienta i nie powinno być wysyłane ani śledzone przez serwer. To, co jest wysyłane do serwera, to kompletny zestaw pól, które należy zmodyfikować w zidentyfikowanym zasobie (przez URI), tak aby nastąpiło przejście w tym zasobie z jednego Stan spoczynku do innego.

Tak więc klient śledzi to, co robi użytkownik i wysyła tylko logicznie kompletne przejścia stanu do serwera.

Transakcja HTTP, basic access authentication, nie jest odpowiednia dla RBAC, ponieważ basic access authentication używa zaszyfrowanego hasła username:password za każdym razem do identyfikacji, podczas gdy w RBAC potrzebna jest rola, której użytkownik chce użyć do określonego połączenia. RBAC nie sprawdza uprawnień dla nazwy użytkownika, ale dla ról.

Można by kombinować tak: usernameRole: password, ale jest to zła praktyka, a także nieefektywna, ponieważ gdy użytkownik ma więcej ról, silnik uwierzytelniania musiałby przetestować wszystkie role w konkatenacji, i że każde połączenie ponownie. Zniszczyłoby to jedną z największych zalet technicznych RBAC, a mianowicie bardzo szybki test autoryzacyjny.

Więc tego problemu nie można rozwiązać przy użyciu podstawowego uwierzytelniania dostępu.

Aby rozwiązać ten problem, utrzymanie sesji jest konieczne, a to wydaje się, według niektórych odpowiedzi, w sprzeczności z odpoczynkiem.

Właśnie to lubię w odpowiedzi, że odpoczynek nie powinien być traktowana jako religia. W złożonych przypadkach biznesowych, na przykład w opiece zdrowotnej, RBAC jest absolutnie powszechne i konieczne. Szkoda by było, gdyby nie pozwolono im korzystać z odpoczynku, ponieważ wszyscy projektanci narzędzi odpoczynku traktowaliby odpoczynek jako religię.

Dla mnie nie ma wielu sposobów na utrzymanie sesji Przez HTTP. Można używać plików cookie, z identyfikatorem sessionId, lub nagłówka z identyfikatorem sessionId.

Jeśli ktoś ma inny pomysł to chętnie go usłyszę.

1. sesje nie są niespokojne
2. masz na myśli tę usługę REST tylko dla HTTP-use czy pomyliłem się? Sesja oparta na plikach Cookie musi być używana tylko dla własnych (!) usługi oparte na http! (Może być problemem praca z ciasteczkiem, np. z telefonu / konsoli / pulpitu / itp.)
3. jeśli świadczysz usługę RESTful dla programistów stron 3D, nigdy nie używaj sesji opartej na plikach cookie, zamiast tego używaj tokenów, aby uniknąć problemów z bezpieczeństwem.