Witam już napisałem tę obserwację i pytanieto pytanie wcześniej, ale dopiero później zauważyłem, że było to stare i „martwe” pytanie. Ponieważ naprawdę chciałbym uzyskać od innych spostrzeżenia, przesyłam je jako nowe pytanie.

Na pytanie, w jaki sposób wykonać uwierzytelnianie RESTfully, ludzie generalnie entuzjastycznie krzyczą „Uwierzytelnianie HTTP”. Jednak wątpię, czy ci ludzie kiedykolwiek próbowali stworzyć przeglądarkępodanie (zamiast usługi internetowej maszyna-maszyna) z REST. (bez obrazy - po prostu nie sądzę, żeby kiedykolwiek mieli do czynienia z komplikacjami)

Problemy z uwierzytelnianiem HTTP w usługach REST, które generują strony HTML do przeglądania w przeglądarce, to:

użytkownik zazwyczaj otrzymuje brzydkie okno logowania do przeglądarki, które jest nieprzyjazne dla użytkownika. nie można dodawać hasła, pól pomocy itp.Wylogowanie lub zalogowanie się pod inną nazwą jest problemem - przeglądarki będą przesyłać informacje uwierzytelniające do witryny, dopóki nie zamkniesz oknalimity czasu są trudne

Bardzo wnikliwy artykuł, który porusza ten punkt po punkcietutaj, ale to powodujelos specyficznej dla przeglądarki hackery javascript, obejścia obejść itp. W związku z tym nie jest kompatybilny z wysyłaniem do przodu, więc będzie wymagał ciągłej konserwacji, gdy nowe przeglądarki zostaną wydane. Nie uważam tego za czysty i przejrzysty projekt, a poza tym czuję, że jest dużo dodatkowej pracy i bólu głowy, tak że mogę entuzjastycznie pokazać moją odznakę REST moim przyjaciołom.

Wierzę, że ciasteczka są rozwiązaniem. Ale poczekaj, ciasteczka są złe, prawda? Nie, nie są, sposób używania plików cookie jest często zły. Sam plik cookie jest tylko częścią informacji po stronie klienta, podobnie jak informacje uwierzytelniające HTTP, które przeglądarka będzie śledzić podczas przeglądania. Ten fragment informacji po stronie klienta jest wysyłany do serwera przy każdym żądaniu, tak jak w przypadku informacji uwierzytelniania HTTP. Koncepcyjnie, jedyną różnicą jest to, żezawartość tego fragmentu stanu po stronie klienta może być określony przezserwer jako część odpowiedzi.

Tworząc sesje jako zasoby RESTful z następującymi regułami:

A sesja odwzorowuje klucz na identyfikator użytkownika (i ewentualnie ostatni znacznik czasu działania dla limitów czasu)Jeślisesja istnieje, to znaczy, że klucz jest ważny.Login oznacza POSTowanie do / sesji, nowy klucz jest ustawiany jako plik cookieWylogowanie oznacza DELETEing / sessions / {key} (z przeciążonym POST, pamiętaj, jesteśmy przeglądarką, a HTML 5 to jeszcze długa droga)Uwierzytelnianie odbywa się poprzez wysłanie klucza w postaci pliku cookie przy każdym żądaniu i sprawdzenie, czy sesja istnieje i jest ważna

Jedyną różnicą w stosunku do uwierzytelniania HTTP jest to, że klucz uwierzytelniający jest generowany przez serwer i wysyłany do klienta, który nadal go wysyła, zamiast do klienta przetwarzającego go z wprowadzonych poświadczeń.

Uważam, że jest to wystarczające rozwiązanie, które działa dobrze, ale muszę przyznać, że nie jestem wystarczającym ekspertem ds. Bezpieczeństwa, aby zidentyfikować potencjalne dziury w tym schemacie - wszystko, co wiem, to to, że setki aplikacji internetowych innych niż REST używają zasadniczo tego samego protokół logowania ($ _SESSION inphp, HttpSession w j2ee, itp.). Zawartość nagłówka pliku cookie jest po prostu używana do adresowania zasobów po stronie serwera, tak jak język akceptacji może być używany do uzyskiwania dostępu do zasobów tłumaczeniowych itp. Czuję, że jest tak samo, ale może inni nie? Co myślicie, chłopaki?