Błąd uwierzytelniania sygnalizacji w RESTful API

Piszę małą aplikację, która udostępnia prosty REST-ish HTTP API. Utknąłem, próbując zdecydować, jak zasygnalizować awarię z powodu braku autoryzacji.Błąd uwierzytelniania sygnalizacji w RESTful API

Aplikacja nie ma interfejsu API do uwierzytelniania, ale zależy od obecności pliku cookie zawierającego token sesji uzyskany przez klienta za pośrednictwem innej usługi. Aplikacja weryfikuje sesję i wykorzystuje tożsamość uzyskaną w procesie weryfikacji do autoryzacji aplikacji. Klient nie może uwierzytelnić się bezpośrednio w tej aplikacji.

Mój problem polega na tym, że oczywisty kod statusu HTTP do odrzucania nieautoryzowanych żądań, "401 Unauthorized", jest określony w nagłówku "WWW-Authenticate". Zobacz rfc2616 sec 10.4.2.

Odpowiedź MUSI zawierać WWW-Authenticate pole nagłówka (sekcja 14,47) zawierające wyzwanie zastosowanie do żądanego zasobu.

Nie mogę uwierzyć, że to nietypowy problem. Czy powszechne jest po prostu przeciążenie 401 w celu uwzględnienia bardziej ogólnych zastosowań? A co z przeglądaniem okien dialogowych auth/e (których przypadkowo nie widziałem w moich testach, więc może nie zdarza się to w przypadku testów POST)?

Podsumowując: czy można używać 401 w tym kontekście, czy jest lepsze rozwiązanie?

Źródło

2009-10-24 j0ni

To nie jest RESTful API, jeśli używasz pliku cookie. Usługi REST są z definicji bezpaństwowcami. –

Fair point - Zmieniłem opis na REST-owski, zamiast RESTful. Czy sądzisz, że odpowiedź brzmi: czy poprawnie wdrożyć uwierzytelnianie na żądanie, czy zrezygnować z próby resteuracji? – j0ni

Trudno powiedzieć, zależy to od zastosowania. Podejście REST ma pewne zalety. Jeśli chcesz nadal korzystać z sesji po stronie serwera, zwrócę 403, jak powiedział Tvanfosson. –

Zazwyczaj chcesz wysłać 401, jeśli klient może uwierzytelnić i rozwiązać problem, ale ponieważ nie zapewniają sposób uwierzytelniania w API, I Sugeruje zamiast tego zwracanie błędu 403 (zabronionego). Nie będzie to wymagało nagłówka i wskaże klientowi, że nie może uzyskać dostępu do usługi.

Źródło

2009-10-24 18:58:54 tvanfosson

Jeśli metodą żądania nie była HEAD, a serwer chciałby podać do publicznej wiadomości, dlaczego wniosek nie został spełniony, POWINIEN opisać przyczynę odmowy w jednostce. Jeśli serwer nie chce udostępnić tych informacji klientowi, można zamiast tego użyć kodu statusu 404 (Nie znaleziono). (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) – vquintans

@ququans 404 nie został znaleziony, wydaje się, że może być niejednoznaczny w tym przypadku. Powiedzmy, że klient żąda określonego zasobu, który może, ale nie musi, ale nie ma pliku cookie? Jak interpretowałbyś błąd 404? Czy się nie udało, ponieważ zasób był niedostępny lub zawierał błąd uwierzytelniania. Trzymałbym się odpowiedzi, która jasno wskazuje na potrzebę autoryzacji. – tvanfosson

Tak, zgadzam się. Ale w każdym razie myślę, że warto zauważyć tę możliwość z RFC. – vquintans

Powrót coś takiego:

HTTP/1.1 401 Unauthorized 
Location: https://example.com/auth-app/login

Źródło

2009-10-24 18:57:58 yfeldblum

Błąd uwierzytelniania sygnalizacji w RESTful API

Odpowiedz

Powiązane problemy