Đăng nhập RESTful không thành công: Trả lại 401 hoặc Phản hồi tùy chỉnh

Đây là một câu hỏi khái niệm.

Tôi có một ứng dụng khách (di động) cần hỗ trợ hành động đăng nhập chống lại dịch vụ web RESTful. Vì dịch vụ web là RESTful, điều này có nghĩa là khách hàng chấp nhận tên người dùng / mật khẩu từ người dùng, xác minh tên người dùng / mật khẩu đó với dịch vụ và sau đó chỉ cần nhớ gửi tên người dùng / mật khẩu đó với tất cả các yêu cầu tiếp theo.

Tất cả các phản hồi khác trong dịch vụ web này đều được cung cấp ở định dạng JSON.

Câu hỏi đặt ra là, khi tôi truy vấn dịch vụ web chỉ để tìm xem tên người dùng / mật khẩu đã cho có hợp lệ hay không, dịch vụ web có phải luôn phản hồi với dữ liệu JSON cho tôi biết nó thành công hay không, hay nó nên trả về HTTP 200 trên thông tin đăng nhập tốt và HTTP 401 trên thông tin đăng nhập không hợp lệ.

Lý do tôi hỏi là một số dịch vụ RESTful khác sử dụng 401 cho thông tin xác thực không hợp lệ ngay cả khi bạn chỉ hỏi xem thông tin đăng nhập có hợp lệ hay không. Tuy nhiên, sự hiểu biết của tôi về các câu trả lời 401 là chúng đại diện cho một tài nguyên mà bạn không được phép truy cập nếu không có thông tin xác thực hợp lệ. Nhưng tài nguyên đăng nhập NÊN có thể truy cập cho bất kỳ ai vì toàn bộ mục đích của tài nguyên đăng nhập là cho bạn biết liệu thông tin đăng nhập của bạn có hợp lệ hay không.

Nói cách khác, đối với tôi dường như một yêu cầu như:

myservice.com/this/is/a/user/action 

sẽ trả về 401 nếu thông tin đăng nhập không hợp lệ được cung cấp. Nhưng một yêu cầu như:

myservice.com/are/these/credentials/valid

không bao giờ được trả về 401 vì URL (yêu cầu) cụ thể đó được cấp phép có hoặc không có thông tin xác thực hợp lệ.

Tôi muốn nghe một số ý kiến ​​xác đáng bằng cách này hay cách khác về vấn đề này. Cách tiêu chuẩn để xử lý vấn đề này là gì và cách tiêu chuẩn để xử lý vấn đề này có hợp lý không?

Trước hết. 401 là mã phản hồi thích hợp để gửi khi đăng nhập không thành công.

401 Unauthorized Tương tự như 403 Forbidden, nhưng đặc biệt để sử dụng khi yêu cầu xác thực và không thành công hoặc chưa được cung cấp. Phản hồi phải bao gồm trường tiêu đề WWW-Authenticate chứa một thử thách áp dụng cho tài nguyên được yêu cầu.

Sự nhầm lẫn của bạn về myservice.com/are/these/credentials/validviệc gửi lại 401 khi bạn vừa kiểm tra, tôi nghĩ dựa trên thực tế là việc thực hiện các yêu cầu boolean trong REST thường là sai bởi các ràng buộc RESTful. Mọi yêu cầu sẽ trả về một tài nguyên. Thực hiện các câu hỏi boolean trong một dịch vụ RESTful là một sự trượt dài đối với RPC.

Bây giờ tôi không biết các dịch vụ mà bạn đã xem đang hoạt động như thế nào. Nhưng một cách tốt để giải quyết vấn đề này là có một cái gì đó giống như một đối tượng Tài khoản, mà bạn cố gắng NHẬN. Nếu thông tin xác thực của bạn là chính xác, bạn sẽ nhận được đối tượng Tài khoản, nếu bạn không muốn lãng phí băng thông chỉ để "kiểm tra", bạn có thể thực hiện HEAD trên cùng một tài nguyên.

Đối tượng Tài khoản cũng là một nơi tuyệt vời để lưu trữ tất cả các giá trị boolean phiền phức mà nếu không sẽ rất khó để tạo các tài nguyên riêng lẻ.

401 chỉ nên được gửi khi yêu cầu cần trường tiêu đề ủy quyền và ủy quyền không thành công. Vì API đăng nhập không yêu cầu ủy quyền, do đó, 401 là mã lỗi sai theo ý kiến ​​của tôi

Theo tiêu chuẩn tại đây https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

* 10.4.2 401 Trái phép

Yêu cầu yêu cầu xác thực người dùng. Phản hồi PHẢI bao gồm trường tiêu đề WWW-Authenticate (mục 14.47) chứa một thử thách áp dụng cho tài nguyên được yêu cầu. Máy khách CÓ THỂ lặp lại yêu cầu với trường tiêu đề Ủy quyền phù hợp (mục 14.8). Nếu yêu cầu đã bao gồm thông tin xác thực Ủy quyền, thì phản hồi 401 cho biết rằng ủy quyền đã bị từ chối đối với các thông tin xác thực đó. Nếu phản hồi 401 chứa cùng một thử thách như phản hồi trước đó và tác nhân người dùng đã cố gắng xác thực ít nhất một lần, thì người dùng NÊN được cung cấp thực thể đã được cung cấp trong phản hồi, vì thực thể đó có thể bao gồm thông tin chẩn đoán có liên quan. Xác thực truy cập HTTP được giải thích trong "Xác thực HTTP: Xác thực truy cập cơ bản và thông báo" [43]. *

Trả về 409 với một thông báo lỗi thích hợp.