Đối với một trang web tồn tại, nhưng người dùng không có đủ đặc quyền (họ không đăng nhập hoặc không thuộc nhóm người dùng phù hợp), phản hồi HTTP thích hợp để phục vụ là gì?

401 Unauthorized?
403 Forbidden?
Thứ gì khác?

Những gì tôi đã đọc trên mỗi cho đến nay không rõ ràng về sự khác biệt giữa hai. Những trường hợp sử dụng phù hợp cho từng phản ứng?

Một lời giải thích rõ ràng từ Daniel Irvine :

Có một vấn đề với 401 Không được phép , mã trạng thái HTTP cho các lỗi xác thực. Và đó chỉ là nó: đó là để xác thực, không phải ủy quyền. Nhận được phản hồi 401 là máy chủ cho bạn biết, bạn không xác thực được, hoặc không được xác thực hoặc xác thực không chính xác, nhưng vui lòng xác nhận lại và thử lại. Để giúp bạn ra ngoài, nó sẽ luôn bao gồm một tiêu đề WWW-xác thực mô tả cách xác thực.

Đây là một phản hồi thường được trả về bởi máy chủ web của bạn, không phải ứng dụng web của bạn.

Đó cũng là một cái gì đó rất tạm thời; máy chủ đang yêu cầu bạn thử lại.

Vì vậy, để ủy quyền tôi sử dụng phản hồi Cấm 403 . Nó là vĩnh viễn, nó gắn liền với logic ứng dụng của tôi và đó là một phản hồi cụ thể hơn so với 401.

Nhận được phản hồi 403 là máy chủ cho bạn biết, tôi xin lỗi. Tôi biết bạn là ai. Tôi tin rằng bạn nói bạn là ai nhưng bạn không được phép truy cập tài nguyên này. Có thể nếu bạn hỏi quản trị viên hệ thống một cách tử tế, bạn sẽ được phép. Nhưng xin đừng làm phiền tôi nữa cho đến khi tình trạng khó khăn của bạn thay đổi.

Tóm lại, nên sử dụng phản hồi trái phép 401 để xác thực bị thiếu hoặc xác thực và phản hồi Cấm 403 nên được sử dụng sau đó, khi người dùng được xác thực nhưng không được phép thực hiện thao tác được yêu cầu trên tài nguyên đã cho.

Một định dạng hình ảnh đẹp khác về cách sử dụng mã trạng thái http.

Xem RFC2616 :

401 trái phép:

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 cho các thông tin đăng nhập đó.

403 Cấm:

Máy chủ hiểu yêu cầu, nhưng từ chối thực hiện nó.

Cập nhật

Từ trường hợp sử dụng của bạn, có vẻ như người dùng không được xác thực. Tôi sẽ trả lại 401.

Chỉnh sửa: RFC2616 đã lỗi thời, xem RFC7231 và RFC7235 .

Một điều mà các câu trả lời khác còn thiếu là phải hiểu rằng Xác thực và Ủy quyền trong ngữ cảnh RFC 2616 CHỈ đề cập đến giao thức Xác thực HTTP của RFC 2617. Xác thực bằng các lược đồ bên ngoài RFC2617 không được hỗ trợ trong mã trạng thái HTTP và không được xem xét khi quyết định nên sử dụng 401 hay 403.

Ngắn gọn và Terse

Không được phép chỉ ra rằng máy khách không được xác thực RFC2617 và máy chủ đang bắt đầu quá trình xác thực. Cấm chỉ ra rằng máy khách là RFC2617 được xác thực và không có ủy quyền hoặc máy chủ không hỗ trợ RFC2617 cho tài nguyên được yêu cầu.

Có nghĩa là nếu bạn có quy trình đăng nhập của riêng mình và không bao giờ sử dụng Xác thực HTTP, 403 luôn là phản hồi thích hợp và không bao giờ nên sử dụng 401.

Chi tiết và chuyên sâu

Từ RFC2616

10.4.2 401 Không được 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-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. 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 (phần 14.8).

và

10.4.4 403 Cấm Máy chủ hiểu yêu cầu nhưng từ chối thực hiện. Ủy quyền sẽ không giúp đỡ và yêu cầu KHÔNG NÊN lặp lại.

Điều đầu tiên cần ghi nhớ là "Xác thực" và "Ủy quyền" trong ngữ cảnh của tài liệu này đề cập cụ thể đến các giao thức Xác thực HTTP từ RFC 2617. Chúng không đề cập đến bất kỳ giao thức xác thực cuộn nào mà bạn có thể đã tạo sử dụng các trang đăng nhập, v.v. Tôi sẽ sử dụng "đăng nhập" để chỉ xác thực và ủy quyền bằng các phương pháp khác ngoài RFC2617

Vì vậy, sự khác biệt thực sự không phải là vấn đề là gì hoặc thậm chí nếu có một giải pháp. Sự khác biệt là những gì máy chủ mong đợi khách hàng sẽ làm tiếp theo.

401 chỉ ra rằng tài nguyên không thể được cung cấp, nhưng máy chủ đang BẮT BUỘC rằng máy khách đăng nhập thông qua Xác thực HTTP và đã gửi các tiêu đề trả lời để bắt đầu quá trình. Có thể có những ủy quyền sẽ cho phép truy cập vào tài nguyên, có thể không có, nhưng hãy thử xem điều gì sẽ xảy ra.

403 chỉ ra rằng tài nguyên không thể được cung cấp và đối với người dùng hiện tại, không có cách nào để giải quyết vấn đề này thông qua RFC2617 và không cần phải cố gắng. Điều này có thể là do được biết rằng không có mức xác thực nào là đủ (ví dụ vì danh sách đen IP), nhưng có thể là do người dùng đã được xác thực và không có thẩm quyền. Mô hình RFC2617 là một người dùng, một thông tin đăng nhập, vì vậy trường hợp người dùng có thể có một bộ thông tin xác thực thứ hai có thể được ủy quyền có thể bị bỏ qua. Nó cũng không gợi ý hay ngụ ý rằng một số loại trang đăng nhập hoặc giao thức xác thực không phải RFC2617 khác có thể hoặc không thể giúp đỡ - điều đó nằm ngoài các tiêu chuẩn và định nghĩa RFC2616.

Chỉnh sửa: RFC2616 đã lỗi thời, xem RFC7231 và RFC7235 .

  + -----------------------
  | NGUỒN TÀI NGUYÊN? (nếu riêng tư, nó thường được kiểm tra SAU kiểm tra xác thực)
  + -----------------------
    | |
 KHÔNG | v CÓ
    v + -----------------------
   404 | ĐƯỢC ĐĂNG NHẬP? (được xác thực, còn có phiên hoặc cookie JWT)
   hoặc + -----------------------
   401 | |
   403 KHÔNG | | ĐÚNG
   3xx vv
              401 + -----------------------
       (404 không tiết lộ) | CÓ THỂ TIẾP CẬN NGUỒN GỐC? (được phép, được ủy quyền, ...)
              hoặc + -----------------------
             chuyển hướng | |
             để đăng nhập KHÔNG | | ĐÚNG
                               | |
                               vv
                               403 OK 200, chuyển hướng, ...
                      (hoặc 404: không tiết lộ)
                      (hoặc 404: tài nguyên không tồn tại nếu riêng tư)
                      (hoặc 3xx: chuyển hướng)

Kiểm tra thường được thực hiện theo thứ tự này:

• 404 nếu tài nguyên là công khai và không tồn tại hoặc chuyển hướng 3xx
• NẾU KHÔNG THÌ:
• 401 nếu không đăng nhập hoặc phiên hết hạn
• 403 nếu người dùng không có quyền truy cập tài nguyên (tệp, json, ...)
• 404 nếu tài nguyên không tồn tại hoặc không sẵn sàng tiết lộ bất cứ điều gì hoặc chuyển hướng 3xx

UNAUTHORIZED : Mã trạng thái (401) cho biết rằng yêu cầu yêu cầu xác thực , thông thường điều này có nghĩa là người dùng cần phải đăng nhập (phiên). Người dùng / đại lý không xác định. Có thể lặp lại với các thông tin khác. LƯU Ý: Điều này gây nhầm lẫn vì điều này nên được đặt tên là 'không được xác thực' thay vì 'trái phép'. Điều này cũng có thể xảy ra sau khi đăng nhập nếu hết hạn phiên. Trường hợp đặc biệt: Có thể được sử dụng thay vì 404 để tránh tiết lộ sự hiện diện hoặc không hiện diện của tài nguyên (tín dụng @gingerCodeNinja)

FORBIDDEN : Mã trạng thái (403) cho biết máy chủ đã hiểu yêu cầu nhưng từ chối thực hiện nó. Người dùng / đại lý được máy chủ biết đến nhưng không có đủ thông tin đăng nhập . Yêu cầu lặp lại sẽ không hoạt động, trừ khi thông tin đăng nhập thay đổi, điều này rất khó xảy ra trong một khoảng thời gian ngắn. Trường hợp đặc biệt: Có thể được sử dụng thay vì 404 để tránh tiết lộ sự hiện diện hoặc không hiện diện của tài nguyên (tín dụng @gingerCodeNinja)

KHÔNG TÌM KIẾM : Mã trạng thái (404) cho biết rằng tài nguyên được yêu cầu không có sẵn. Người dùng / tác nhân được biết đến nhưng máy chủ sẽ không tiết lộ bất cứ điều gì về tài nguyên, như thể nó không tồn tại. Lặp đi lặp lại sẽ không hoạt động. Đây là một cách sử dụng đặc biệt của 404 (ví dụ github làm điều đó).

Như được đề cập bởi @ChrisH, có một vài tùy chọn để chuyển hướng 3xx (301, 302, 303, 307 hoặc không chuyển hướng chút nào và sử dụng 401):

• Sự khác biệt giữa các mã chuyển hướng HTTP
• Làm thế nào lâu trình duyệt cache HTTP 301s?
• Mã trạng thái HTTP chính xác khi chuyển hướng đến trang đăng nhập là gì?
• Sự khác biệt giữa chuyển hướng 302 và 307 là gì?

Theo RFC 2616 (HTTP / 1.1) 403 được gửi khi:

Máy chủ hiểu yêu cầu, nhưng từ chối thực hiện nó. Ủy quyền sẽ không giúp đỡ và yêu cầu KHÔNG NÊN lặp lại. Nếu phương thức yêu cầu không phải là CHÍNH và máy chủ muốn công khai lý do tại sao yêu cầu chưa được thực hiện, thì NÊN mô tả lý do từ chối trong thực thể. Nếu máy chủ không muốn cung cấp thông tin này cho khách hàng, mã trạng thái 404 (Không tìm thấy) có thể được sử dụng thay thế

Nói cách khác, nếu khách hàng CÓ THỂ có quyền truy cập vào tài nguyên bằng cách xác thực, thì nên gửi 401.

Giả sử xác thực HTTP ( tiêu đề WWW-xác thực và ủy quyền ) đang được sử dụng , nếu xác thực là người dùng khác sẽ cấp quyền truy cập vào tài nguyên được yêu cầu, thì phải trả lại 401 trái phép.

403 Cấm được sử dụng khi mọi người truy cập vào tài nguyên bị cấm hoặc bị hạn chế đối với một mạng nhất định hoặc chỉ được phép qua SSL, miễn là nó không liên quan đến xác thực HTTP.

Nếu xác thực HTTP không được sử dụng và dịch vụ là sơ đồ xác thực dựa trên cookie như hiện nay, thì phải trả lại 403 hoặc 404.

Liên quan đến 401, đây là từ RFC 7235 (Giao thức truyền siêu văn bản (HTTP / 1.1): Xác thực):

3.1. 401 trái phép

Mã trạng thái 401 (Không được phép) cho biết rằng yêu cầu chưa được áp dụng vì nó thiếu thông tin xác thực hợp lệ cho tài nguyên đích. Máy chủ gốc PHẢI gửi trường tiêu đề Xác thực WWW (Phần 4.4) có ít nhất một thách thức áp dụng cho tài nguyên đích. Nếu yêu cầu bao gồm thông tin xác thực, 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 đó. Máy khách CÓ THỂ lặp lại yêu cầu với trường tiêu đề Ủy quyền mới hoặc được thay thế (Phần 4.1). Nếu phản hồi 401 có cùng thách thức với phản hồi trước đó và tác nhân người dùng đã thử xác thực ít nhất một lần, thì tác nhân người dùng NÊN trình bày đại diện kèm theo cho người dùng, vì nó thường chứa thông tin chẩn đoán liên quan.

Các ngữ nghĩa của 403 (và 404) đã thay đổi theo thời gian. Đây là từ năm 1999 (RFC 2616):

10,4,4 403 Cấm

Máy chủ hiểu yêu cầu, nhưng từ chối thực hiện nó.
Ủy quyền sẽ không giúp đỡ và yêu cầu KHÔNG NÊN lặp lại.
Nếu phương thức yêu cầu không phải là CHÍNH và máy chủ muốn
công khai lý do tại sao yêu cầu chưa được thực hiện, thì NÊN mô tả lý do từ chối trong thực thể. Nếu máy chủ không muốn cung cấp thông tin này cho khách hàng, mã trạng thái 404
(Không tìm thấy) có thể được sử dụng thay thế.

Năm 2014 RFC 7231 (Giao thức truyền siêu văn bản (HTTP / 1.1): Ngữ nghĩa và nội dung) đã thay đổi ý nghĩa của 403:

6.5.3. 403 Cấm

Mã trạng thái 403 (Bị cấm) chỉ ra rằng máy chủ hiểu yêu cầu nhưng từ chối ủy quyền. Một máy chủ muốn công khai lý do tại sao yêu cầu bị cấm có thể mô tả lý do đó trong tải trọng phản hồi (nếu có).

Nếu thông tin xác thực được cung cấp trong yêu cầu,
máy chủ cho rằng chúng không đủ để cấp quyền truy cập. Khách hàng
KHÔNG NÊN tự động lặp lại yêu cầu với cùng
thông tin đăng nhập. Khách hàng CÓ THỂ lặp lại yêu cầu với thông tin mới hoặc khác. Tuy nhiên, một yêu cầu có thể bị cấm vì những lý do
không liên quan đến thông tin đăng nhập.

Thay vào đó, một máy chủ gốc muốn "ẩn" sự tồn tại của tài nguyên đích bị cấm CÓ THỂ trả lời bằng mã trạng thái
404 (Không tìm thấy).

Do đó, 403 (hoặc 404) bây giờ có thể có nghĩa là về bất cứ điều gì. Cung cấp thông tin đăng nhập mới có thể giúp ... hoặc có thể không.

Tôi tin rằng lý do tại sao điều này đã thay đổi là RFC 2616 giả định xác thực HTTP sẽ được sử dụng khi trong thực tế các ứng dụng Web ngày nay xây dựng các sơ đồ xác thực tùy chỉnh bằng cách sử dụng các biểu mẫu và cookie ví dụ.

Đây là một câu hỏi cũ hơn, nhưng một lựa chọn chưa bao giờ thực sự được đưa ra là trả về 404. Từ góc độ bảo mật, câu trả lời được bình chọn cao nhất phải chịu lỗ hổng rò rỉ thông tin tiềm năng . Ví dụ, giả sử rằng trang web bảo mật được đề cập là trang quản trị hệ thống, hoặc có lẽ phổ biến hơn, là một bản ghi trong hệ thống mà người dùng không có quyền truy cập. Lý tưởng nhất là bạn sẽ không muốn một người dùng độc hại thậm chí biết rằng có một trang / bản ghi ở đó, chứ đừng nói là họ không có quyền truy cập. Khi tôi xây dựng một cái gì đó như thế này, tôi sẽ cố gắng ghi lại các yêu cầu không được xác thực / trái phép trong nhật ký nội bộ, nhưng trả về 404.

OWASP có thêm một số thông tin về cách kẻ tấn công có thể sử dụng loại thông tin này như một phần của cuộc tấn công.

• 401 Không được phép : Tôi không biết bạn là ai. Đây là một lỗi xác thực.
• 403 Cấm : Tôi biết bạn là ai, nhưng bạn không được phép truy cập tài nguyên này. Đây là một lỗi ủy quyền.

Câu hỏi này đã được hỏi cách đây một thời gian, nhưng suy nghĩ của mọi người tiếp tục.

Mục 6.5.3 trong dự thảo này (được soạn thảo bởi Fielding và Reschke) cung cấp mã trạng thái 403 có ý nghĩa hơi khác với tài liệu trong RFC 2616 .

Nó phản ánh những gì xảy ra trong các chương trình xác thực và ủy quyền được sử dụng bởi một số máy chủ và khung web phổ biến.

Tôi đã nhấn mạnh một chút mà tôi nghĩ là mặn mà nhất.

6.5.3. 403 Cấm

Mã trạng thái 403 (Bị cấm) chỉ ra rằng máy chủ hiểu yêu cầu nhưng từ chối ủy quyền. Một máy chủ muốn công khai lý do tại sao yêu cầu bị cấm có thể mô tả lý do đó trong tải trọng phản hồi (nếu có).

Nếu thông tin xác thực được cung cấp trong yêu cầu, máy chủ cho rằng chúng không đủ để cấp quyền truy cập. Khách hàng KHÔNG NÊN lặp lại yêu cầu với cùng thông tin đăng nhập. Khách hàng CÓ THỂ lặp lại yêu cầu với thông tin mới hoặc khác. Tuy nhiên, một yêu cầu có thể bị cấm vì những lý do không liên quan đến thông tin đăng nhập.

Thay vào đó, một máy chủ gốc muốn "ẩn" sự tồn tại của tài nguyên đích bị cấm CÓ THỂ trả lời bằng mã trạng thái 404 (Không tìm thấy).

Dù bạn sử dụng quy ước nào, điều quan trọng là cung cấp tính đồng nhất trên trang web / API của bạn.

TL; DR

• 401: Một sự từ chối liên quan đến xác thực
• 403: Một sự từ chối không liên quan đến xác thực

Ví dụ thực tế

Nếu apache yêu cầu xác thực (thông qua .htaccess) và bạn nhấn Cancel, nó sẽ phản hồi bằng401 Authorization Required

Nếu nginx tìm thấy một tệp, nhưng không có quyền truy cập (người dùng / nhóm) để đọc / truy cập nó, nó sẽ phản hồi với403 Forbidden

RFC (2616 Mục 10)

401 trái phép (10.4.2)

Ý nghĩa 1: Cần xác thực

Yêu cầu yêu cầu xác thực người dùng. ...

Ý nghĩa 2: Xác thực không đủ

... 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 cho các thông tin đăng nhập đó. ...

403 Cấm (10.4.4)

Ý nghĩa: Không liên quan đến xác thực

... Ủy quyền sẽ không giúp ...

Thêm chi tiết:

• Máy chủ hiểu yêu cầu, nhưng từ chối thực hiện nó.

• Nó NÊN mô tả lý do từ chối trong thực thể

• Mã trạng thái 404 (Không tìm thấy) có thể được sử dụng thay thế

  (Nếu máy chủ muốn giữ thông tin này từ khách hàng)

họ không đăng nhập hoặc không thuộc nhóm người dùng thích hợp

Bạn đã nêu hai trường hợp khác nhau; mỗi trường hợp nên có một phản ứng khác nhau:

1. Nếu họ chưa đăng nhập, bạn nên trả lại trái phép 401
2. Nếu họ đã đăng nhập nhưng không thuộc nhóm người dùng phù hợp, bạn nên trả lại 403 Bị cấm

Lưu ý về RFC dựa trên các nhận xét nhận được cho câu trả lời này:

Nếu người dùng không đăng nhập thì họ không được xác thực, tương đương HTTP là 401 và được gọi nhầm là Không được phép trong RFC. Như mục 10.4.2 nêu rõ về 401 Không được phép :

"Yêu cầu yêu cầu xác thực người dùng ."

Nếu bạn không được xác thực, 401 là phản hồi chính xác. Tuy nhiên, nếu bạn không được ủy quyền, theo nghĩa chính xác về mặt ngữ nghĩa, 403 là phản hồi chính xác.

Đây là những ý nghĩa:

401 : Người dùng không được xác thực (chính xác), tài nguyên / trang yêu cầu xác thực

403 : Người dùng được xác thực, nhưng vai trò hoặc quyền của anh ta không cho phép truy cập tài nguyên được yêu cầu, ví dụ người dùng không phải là quản trị viên và trang được yêu cầu dành cho quản trị viên

Điều này đơn giản trong đầu tôi hơn bất cứ nơi nào ở đây, vì vậy:

401: Bạn cần xác thực cơ bản HTTP để thấy điều này.

403: Bạn không thể thấy điều này và xác thực cơ bản HTTP sẽ không giúp đỡ.

Nếu người dùng chỉ cần đăng nhập bằng biểu mẫu đăng nhập HTML tiêu chuẩn của trang web của bạn, thì 401 sẽ không phù hợp vì nó đặc trưng cho xác thực cơ bản HTTP.

Tôi không khuyên bạn nên sử dụng 403 để từ chối quyền truy cập vào những thứ như /includes, vì theo như web có liên quan, những tài nguyên đó hoàn toàn không tồn tại và do đó nên 404.

Điều này để lại 403 là "bạn cần phải đăng nhập".

Nói cách khác, 403 có nghĩa là "tài nguyên này yêu cầu một số hình thức xác thực khác với xác thực cơ bản HTTP".

https://www.w3.org/Prot Protocol / rfc2616 / rfc2616-sec10.html # sec10.4.2

Tôi nghĩ điều quan trọng là phải xem xét rằng, đối với trình duyệt, 401 khởi tạo hộp thoại xác thực để người dùng nhập thông tin đăng nhập mới, trong khi 403 thì không. Các trình duyệt nghĩ rằng, nếu trả về một 401, thì người dùng nên xác thực lại. Vì vậy, 401 là viết tắt của xác thực không hợp lệ trong khi 403 là thiếu sự cho phép.

Dưới đây là một số trường hợp theo logic đó trong đó lỗi sẽ được trả về từ xác thực hoặc ủy quyền, với các cụm từ quan trọng được in đậm.

• Một tài nguyên yêu cầu xác thực nhưng không có thông tin xác thực được chỉ định .

401 : Khách hàng nên chỉ định thông tin đăng nhập.

• Thông tin đăng nhập được chỉ định ở định dạng không hợp lệ .

400 : Đó không phải là 401 hay 403, vì lỗi cú pháp sẽ luôn trả về 400.

• Các thông tin cụ thể tham khảo một người sử dụng mà không tồn tại .

401 : Khách hàng nên chỉ định thông tin hợp lệ.

• Thông tin đăng nhập được chỉ định không hợp lệ nhưng chỉ định người dùng hợp lệ (hoặc không chỉ định người dùng nếu không yêu cầu người dùng được chỉ định).

401 : Một lần nữa, khách hàng nên chỉ định thông tin đăng nhập hợp lệ.

• Các thông tin xác định đã hết hạn .

401 : Điều này thực tế giống như có thông tin không hợp lệ nói chung, vì vậy khách hàng nên chỉ định thông tin xác thực hợp lệ.

• Thông tin đăng nhập được chỉ định là hoàn toàn hợp lệ nhưng không đủ tài nguyên cụ thể , mặc dù có thể thông tin đăng nhập có nhiều quyền hơn có thể.

403 : Chỉ định thông tin xác thực hợp lệ sẽ không cấp quyền truy cập vào tài nguyên, vì thông tin đăng nhập hiện tại đã hợp lệ nhưng chỉ không có quyền.

• Tài nguyên cụ thể là không thể truy cập bất kể thông tin đăng nhập.

403 : Đây là bất kể thông tin đăng nhập, vì vậy việc chỉ định thông tin xác thực hợp lệ có thể giúp ích.

• Các chứng chỉ quy định là hoàn toàn hợp lệ nhưng đặc biệt là khách hàng đang bị chặn từ việc sử dụng chúng.

403 : Nếu máy khách bị chặn, việc chỉ định thông tin đăng nhập mới sẽ không làm gì cả.

Bằng tiếng Anh:

401

Bạn có khả năng được phép truy cập nhưng vì một số lý do cho yêu cầu này, bạn đã bị từ chối. Chẳng hạn như một mật khẩu xấu? Hãy thử lại, với yêu cầu chính xác, bạn sẽ nhận được phản hồi thành công thay thế.

403

Bạn không, bao giờ, được cho phép. Tên của bạn không có trong danh sách, bạn sẽ không bao giờ vào được, biến đi, đừng gửi yêu cầu thử lại, nó sẽ luôn bị từ chối. Đi chỗ khác.

Với các RFC mới nhất về vấn đề này ( 7231 và 7235 ), trường hợp sử dụng có vẻ khá rõ ràng (in nghiêng thêm):

• 401 là không xác thực ("thiếu xác thực hợp lệ"); tức là 'Tôi không biết bạn là ai, hoặc tôi không tin bạn là bạn nói bạn là ai.'

401 trái phép

Mã trạng thái 401 (Không được phép) cho biết rằng yêu cầu chưa được áp dụng vì thiếu xác thực hợp lệ thông tin cho tài nguyên đích. Máy chủ tạo phản hồi 401 PHẢI gửi trường tiêu đề Xác thực WWW (Phần 4.1) có chứa ít nhất một thách thức áp dụng cho tài nguyên đích.

Nếu yêu cầu bao gồm thông tin xác thực, thì phản hồi 401 cho biết rằng ủy quyền đã bị từ chối cho các thông tin xác thực đó. Tác nhân người dùng CÓ THỂ lặp lại yêu cầu với trường tiêu đề Ủy quyền mới hoặc được thay thế (Mục 4.2). Nếu phản hồi 401 có cùng thách thức với phản hồi trước đó và tác nhân người dùng đã thử xác thực ít nhất một lần, thì tác nhân người dùng NÊN trình bày đại diện kèm theo cho người dùng, vì nó thường chứa thông tin chẩn đoán liên quan.

• 403 là trái phép ("từ chối ủy quyền"); tức là 'Tôi biết bạn là ai, nhưng bạn không có quyền truy cập tài nguyên này.'

403 Cấm

Mã trạng thái 403 (Bị cấm) chỉ ra rằng máy chủ hiểu yêu cầu nhưng từ chối ủy quyền . Một máy chủ muốn công khai lý do tại sao yêu cầu bị cấm có thể mô tả lý do đó trong tải trọng phản hồi (nếu có).

Nếu thông tin xác thực được cung cấp trong yêu cầu, máy chủ cho rằng chúng không đủ để cấp quyền truy cập. Khách hàng KHÔNG NÊN tự động lặp lại yêu cầu với cùng thông tin đăng nhập. Khách hàng CÓ THỂ lặp lại yêu cầu với thông tin mới hoặc khác. Tuy nhiên, một yêu cầu có thể bị cấm vì những lý do không liên quan đến thông tin đăng nhập.

Thay vào đó, một máy chủ gốc muốn "ẩn" sự tồn tại của tài nguyên đích bị cấm CÓ THỂ trả lời bằng mã trạng thái 404 (Không tìm thấy).

Trong trường hợp 401 so với 403, điều này đã được trả lời nhiều lần. Đây thực chất là một cuộc tranh luận 'môi trường yêu cầu HTTP, không phải là cuộc tranh luận về' ứng dụng '.

Dường như có một câu hỏi về vấn đề đăng nhập (ứng dụng) của chính bạn.

Trong trường hợp này, chỉ cần không đăng nhập là không đủ để gửi 401 hoặc 403, trừ khi bạn sử dụng HTTP Auth so với trang đăng nhập (không bị ràng buộc để đặt HTTP Auth). Có vẻ như bạn có thể đang tìm kiếm "201 Tạo", với màn hình đăng nhập của chính bạn (thay vì tài nguyên được yêu cầu) để truy cập cấp độ ứng dụng vào một tệp. Điều này nói rằng:

"Tôi nghe thấy bạn, nó ở đây, nhưng hãy thử điều này thay vào đó (bạn không được phép nhìn thấy nó)"