2012-06-26 31 views
10

Tôi đang phát triển một API cũng sẽ có thành phần xác thực/ủy quyền. Bất kỳ ai, bất kể trạng thái xác thực, sẽ có thể viết (POST), nhưng tùy thuộc vào việc bạn chưa được xác thực, được xác thực là người dùng bình thường hay được xác thực là quản trị viên và tài nguyên nào bạn đang cố gắng truy cập, tôi sẽ để trả về các câu trả lời khác nhau cho GET, DELETE và PUT.Tôi có nên trả lại mã phản hồi 401 hoặc 405 cho người dùng REST API mà không có quyền truy cập đầy đủ không?

Tôi đang cố gắng tìm ra mã phản hồi thích hợp nhất cho người dùng không được xác thực và/hoặc được ủy quyền.

Hãy nhớ http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html:

trái phép -> 401

Forbidden -> 403

Phương pháp không được phép -> 405

Hãy sử dụng một ví dụ cụ thể:

  • John Doe chưa được xác thực, DELETE có nhận được 401 hoặc 405 không?
  • Amy được xác thực nhưng không được ủy quyền, trên DELETE cô ấy có nhận được 403 hoặc 405 không?

(Hãy ghi nhớ rằng mặc dù John và Amy cấm hoặc trái phép đó không có nghĩa họ arent thể truy cập vào tài nguyên cùng với một ĐỘNG TỪ HTTP khác nhau.)

Cảm ơn.

+0

Xem thêm http://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses – Ryan

+0

Vì vậy, John sẽ nhận được 401, Amy sẽ nhận được 403. – Ryan

+0

405 Phương pháp không được phép có vẻ [hoàn toàn không liên quan] (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html). – Ryan

Trả lời

11

405 Method Not Allowed chỉ nên được sử dụng nếu bạn không hỗ trợ phương pháp. Nó không nên được sử dụng để nói với khách hàng rằng họ không thể sử dụng phương pháp này.

Vì vậy, chỉ có mã HTTP tốt trong trường hợp của bạn là 401 Unauthorized. Nó chỉ ra cho khách hàng rằng phương thức tồn tại và họ cần đăng nhập để truy cập nó.

+3

Hầu như. Khi bạn đã được xác thực, nhưng không được phép thực hiện thao tác, nó sẽ là 403. –

+0

@JulianReschke, hmmm không chắc chắn. Đối với 403, tiêu chuẩn nói rằng "Không giống như một phản ứng không được phép 401, việc xác thực sẽ không tạo ra sự khác biệt". Nhưng trong trường hợp này, xác thực * sẽ * tạo sự khác biệt vì nó sẽ cho phép truy cập tài nguyên. –

+2

Laurent: "Máy chủ đã hiểu yêu cầu, nhưng từ chối cho phép. Cung cấp thông tin xác thực người dùng khác nhau có thể thành công, nhưng mọi thông tin đăng nhập được cung cấp trong yêu cầu đều không đủ. Yêu cầu KHÔNG được lặp lại với cùng thông tin đăng nhập". - http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#status.403 –

7

Trong trường hợp này, tôi nghĩ cung cấp một số ví dụ để làm rõ có ích:

  • Unauthenticated + phương pháp hỗ trợ = 401
  • Unauthenticated + phương pháp không được hỗ trợ = 405
  • Authenticated + ủy quyền + Phương pháp hỗ trợ = 2xx
  • Được xác thực + Đã ủy quyền + Phương thức không được hỗ trợ = 405
  • Au Phương pháp hỗ trợ thenticated + trái phép + = 403
  • Authenticated + trái phép + Phương pháp không được hỗ trợ = 405

Nói cách khác, từ một quan điểm về thủ tục:

  1. Kiểm tra xem phương pháp được hỗ trợ. Nếu không: 405
  2. Nếu được hỗ trợ, hãy kiểm tra xem người dùng có được xác thực hay không. Nếu không: 401
  3. Nếu được xác thực, hãy kiểm tra xem người dùng có được ủy quyền hay không. Nếu không được: 403
  4. Nếu ủy quyền: 2xx

EDIT: tôi stumbled khi sơ đồ này và nghĩ rằng nó có thể có ích cho bất kỳ ai khác có thể vấp ngã trên bài đăng này. Nhấn vào đây để phóng to.

enter image description here

gốc here.

+1

Chà, điều đó cực kỳ chi tiết. Tôi cầu nguyện cho các vị thần nhà phát triển, tôi sẽ không bao giờ cần sử dụng hơn 5% biểu đồ lưu lượng này. –

Các vấn đề liên quan