Tôi có nên trả lại mã trạng thái http 401 trên biểu mẫu đăng nhập dựa trên html không?

Tôi có nên trả lại mã trạng thái http 401 trên biểu mẫu đăng nhập dựa trên html không? Trang này là một hình thức đăng nhập chuyên dụng và không có bất kỳ nội dung có ý nghĩa nào khác, chỉ là khung trang web. Tuy nhiên, URL có thể dành cho một trang có nội dung có ý nghĩa nhưng yêu cầu đăng nhập. Lưu ý rằng thiết lập này chỉ trả về mã trạng thái 401 và không nhắc người dùng xác thực cơ bản.

Nhìn vào các tiêu chuẩn, có vẻ như 401 là một mã trạng thái không phù hợp cho các hình thức đăng nhập dựa trên html. Tuy nhiên, tôi chưa bao giờ trải nghiệm hoặc nghe về bất kỳ hậu quả xấu nào khi làm như vậy.

Khi gửi 401, "Phản hồi PHẢI bao gồm trường tiêu đề WWW-xác thực (phần 14.47) có chứa một thách thức áp dụng cho tài nguyên được yêu cầu."

yêu cầu được đề cập ở đây:

http://tools.ietf.org/html/rfc2616#section-10.4.2

chi tiết tại đây:

http://tools.ietf.org/html/rfc2617#section-3.2.1

Tôi biết có những cách mà tôi có thể làm việc xung quanh các công cụ tìm kiếm để thuyết phục họ lập chỉ mục, hoặc không, các trang dựa trên sự hiện diện của biểu mẫu đăng nhập, nhưng tôi thích sử dụng mã trạng thái http, cụ thể là 401 vì định nghĩa của nó có vẻ giống như kết hợp hoàn hảo nếu không có yêu cầu tiêu đề WWW-xác thực.

Có bất kỳ lý do tại sao tôi không nên sử dụng 401 trong trường hợp này? Về mặt ngữ nghĩa có sự khác biệt nào giữa việc không được ủy quyền ở cấp http so với được ủy quyền ở cấp ứng dụng không? Rõ ràng bạn có thể có cả hai, nhưng không xác thực ở cấp http chỉ để dễ thực hiện ở cấp ứng dụng?

Như bạn lưu ý, RFC 2616 yêu cầu phản hồi 401 phải đi kèm với tiêu đề RFC 2617 WWW-xác thực. Tôi cho rằng về mặt kỹ thuật bạn có thể tuân thủ yêu cầu đó bằng cách gửi tiêu đề không có thật như:

WWW-Authenticate: Bogus realm="blahblah", comment="use form to log in"

nhưng tôi không biết trình duyệt sẽ làm gì nếu được trình bày với phản hồi 401 không chứa những thách thức mà họ hiểu. Tôi cho rằng hầu hết nếu không phải tất cả trong số họ sẽ trình bày phần yêu cầu cho người dùng (như RFC 2616 nói họ nên làm nếu xác thực thất bại), nhưng RFC dường như không nói rõ ràng, vì vậy họ có thể chỉ hiển thị một thông báo lỗi chung thay thế.

Một giải pháp thay thế khả thi (nếu bạn không muốn chỉ sử dụng 200 phản hồi như mọi người khác dường như sẽ làm) sẽ sử dụng mã trạng thái 403 Cấm . Đây là một mã phản hồi được sử dụng rộng rãi và theo như tôi biết, hầu như tất cả các tác nhân người dùng tương tác (ví dụ như các trình duyệt, trái với, các công cụ tìm kiếm hoặc trình quản lý tải xuống) nên phản ứng với nó bằng cách trình bày nội dung cho người dùng, ít nhất là nếu nó đủ dài .

Mặc dù mô tả về mã trạng thái 403 nói rằng "[a] việc sử dụng không có ích", nhưng IMO nên được hiểu trong ngữ cảnh khi đề cập đến xác thực RFC 2617 hoặc các cơ chế ủy quyền cấp giao thức tương tự; đối với trình duyệt có liên quan, nó không biết liệu việc gửi biểu mẫu và nhận cookie trong phản hồi có được tính là "ủy quyền" hay điều gì khác không.

Một cơ chế được sử dụng phổ biến hơn là đáp ứng các yêu cầu chưa được xác thực bằng chuyển hướng tạm thời đến một trang đăng nhập riêng, với URL gốc được truyền dưới dạng tham số để người dùng có thể được chuyển hướng trở lại sau khi xác thực thành công. Tuy nhiên, lưu ý rằng việc triển khai ngây thơ có thể cho phép kẻ độc hại tạo liên kết đăng nhập sẽ chuyển hướng người dùng đến một URL tùy ý sau khi đăng nhập. Nếu đây có thể là vấn đề bảo mật, bạn nên thực hiện các bước để ngăn chặn, ví dụ: chỉ chấp nhận trả về các URL khớp với mẫu an toàn đã biết hoặc bằng cách bảo vệ URL trả về bằng mã xác thực thư để ngăn sửa đổi.

Trong mọi trường hợp, nếu bạn đang sử dụng cookie HTTP để lưu trữ mã thông báo xác thực sau khi đăng nhập, bạn nên bao gồm tiêu đề Vary trong các phản hồi của mình (cả trước và sau khi xác thực) để ngăn chặn bộ đệm ẩn không phù hợp, như trong Vary: Cookie.

Đầu tiên, nếu trang cần đăng nhập, thì có lẽ bạn nên chặn nó bằng robot.txt

Thứ hai, nếu robot đến được trang, một lỗi 401 là đúng.

có lẽ, mã trạng thái có thể hữu ích cho người không [và cho một số trình duyệt? ]

độc lập với phương thức đăng nhập, tiêu đề chính xác phải được gửi

ví dụ trong tương lai bạn có thể cần phải viết một trình khách trình bao bọc (không phải trình duyệt web) mà chỉ đơn giản là sẽ tự xác thực bằng cách yêu cầu các tiêu đề trang, chứ không phải toàn bộ mã html

bạn có thể triển khai ứng dụng đăng nhập của mình bằng cả hai phương pháp bằng cùng một cơ sở dữ liệu như danh sách người dùng