2012-06-26 12 views
10

Zajmuję się tworzeniem API, które będzie miało również element uwierzytelniania/autoryzacji.Czy powinienem zwrócić kod odpowiedzi 401 lub 405 do użytkownika REST API bez wystarczającego dostępu?

Każdy, niezależnie od statusu uwierzytelnienia, będzie mógł pisać (POST), ale w zależności od tego, czy jesteś nieuwierzytelniony, uwierzytelniony jako zwykły użytkownik lub uwierzytelniony jako administrator i do jakiego zasobu próbujesz uzyskać dostęp Idę aby zwrócić różne odpowiedzi dla GET, DELETE i PUT.

Próbuję znaleźć najbardziej odpowiedni kod odpowiedzi dla użytkownika, który nie jest uwierzytelniony i/lub autoryzowany.

Pamiętaj http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html:

Nieuprawnione -> 401

zabronione -> 403

Method Not Allowed -> 405

użyjmy konkretne przykłady:

  • John Doe jest nieuwierzytelniony, na DELETE powinien otrzymać 401 lub 405?
  • Amy jest uwierzytelniona, ale nie autoryzowana, w przypadku USUŃ powinna otrzymać 403 lub 405?

(Należy pamiętać, że chociaż John i Amy są zakazane lub nieautoryzowane to nie znaczy, oni nie jest w stanie uzyskać dostęp do tych samych zasobów z innym czasownikiem HTTP.)

Dzięki.

+0

See http://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses również – Ryan

+0

Więc John powinien dostać 401, Amy powinna dostać 403. – Ryan

+0

405 Method Not Allowed wydaje [całkowicie niepowiązane] (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html). – Ryan

Odpowiedz

11

405 Method Not Allowed należy używać tylko wtedy, gdy You nie obsługuje tej metody. Nie należy go używać do informowania klienta, że ​​nie może użyć tej metody.

Tak więc jedynym dobrym kodem HTTP w twoim przypadku byłby 401 Unauthorized. Wskazuje klienta, że ​​metoda istnieje i potrzebuje logowania, aby uzyskać do niego dostęp.

+3

Prawie. Po uwierzytelnieniu, ale nie możesz wykonać tej operacji, będzie to 403. –

+0

@JulianReschke, hmmm nie jestem pewien. W przypadku standardu 403 standard stwierdza, że ​​"w przeciwieństwie do 401 nieautoryzowanej odpowiedzi uwierzytelnianie nie ma znaczenia". Ale w tym przypadku uwierzytelnienie * może * spowodować różnicę, ponieważ umożliwi dostęp do zasobu. –

+2

Laurent: "Serwer zrozumiał żądanie, ale odmawia autoryzacji. Podanie różnych poświadczeń uwierzytelniających użytkownika może się powieść, ale wszelkie poświadczenia podane w żądaniu są niewystarczające. ŻĄDANIE NIE POWINIEN być powtarzane z tymi samymi danymi uwierzytelniającymi." - http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#status.403 –

7

W tym przypadku, myślę zapewniając pewne przykłady wyjaśnienia są użyteczne:

  • Nieuwierzytelnionego + Obsługiwane metoda = 401
  • Nieuwierzytelnionego + Sposób NieobsĹ,ugiwana = 405
  • Uwierzytelnianie + Upoważniony + Obsługiwane metoda = 2xx
  • Uwierzytelniona + autoryzowana + nieobsługiwana metoda = 405
  • Au thenticated + Nieuprawnione + Obsługiwane method = 403
  • przysięgłe + Nieuprawnione + Metoda nieobsługiwana = 405

Innymi słowy, z punktu widzenia proceduralnego:

  1. Sprawdź, czy metody są obsługiwane. Jeśli nie: 405
  2. Jeśli jest obsługiwana, sprawdź, czy użytkownik jest uwierzytelniony. Jeśli nie: 401
  3. Po uwierzytelnieniu sprawdź, czy użytkownik jest uprawniony. Jeśli nie: 403
  4. jeżeli uprawniony: 2xx

EDIT: natknąłem się na tym schemacie i że może to być przydatne dla każdego, kto może natknąć tego postu. Kliknij, aby powiększyć.

enter image description here

Original here.

+1

Wow, to jest niesamowicie szczegółowe. Modlę się do bogów programistów, że nigdy nie będę musiał używać więcej niż 5% tego schematu. –