a

Câu hỏi 403 Forbidden vs 401 Phản hồi HTTP không được ủy quyền


Đối với một trang web tồn tại, nhưng mà người dùng không có đủ đặc quyền, (họ không đăng nhập hoặc không thuộc về nhóm người dùng thích hợp), phản hồi HTTP thích hợp để phục vụ là gì? 401? 403? Thứ gì khác? Những gì tôi đã đọc trên mỗi cho đến nay không phải là rất rõ ràng về sự khác biệt giữa hai. Những trường hợp sử dụng nào thích hợp cho mỗi câu trả lời?


1905
2017-07-21 07:21


gốc


401 'Không được phép' nên là 401 'Chưa được xác thực', đã giải quyết được vấn đề! - Christophe Roussy
Wow. Các câu trả lời dưới đây rất lố bịch trên bản đồ. Dường như câu trả lời đúng là không xác định cho xác thực không phải HTTP. - Joe Lapp
Tôi không nhớ bao nhiêu lần tôi và đồng nghiệp của tôi đã trở lại với stackoverflow cho câu hỏi này. Có lẽ các tiêu chuẩn HTTP nên xem xét sửa đổi tên hoặc mô tả cho 401 và 403. - neurite
Trong thực tế, tôi nhận được một phiên bản khác của lỗi này. như "os_authType là 'bất kỳ' và một cookie không hợp lệ đã được gửi". Vì vậy, không thể tìm ra cách để giải quyết điều đó. Googled rất nhiều thời gian, có lý do nhưng không nhận được một giải pháp. - Sandeep Anand
@ Qwerty không, RFC7231 lỗi thời mới RFC2616. 403 có ý nghĩa khác. - fishbone


Các câu trả lời:


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

Có vấn đề với 401 trái 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, chứ 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 phải là   được xác thực - hoặc không được xác thực ở tất cả hoặc được xác thực   không chính xác – nhưng vui lòng xác thực lại và thử lại. ”Để giúp bạn,   nó sẽ luôn bao gồm WWW-Xác thực tiêu đề mô tả cách   để xác thực.

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

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

Vì vậy, để cho phép tôi sử dụng 403 Cấm phản ứng. Nó là   vĩnh viễn, nó gắn liền với logic ứng dụng của tôi và nó càng cụ thể hơn   phản hồi hơn 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 bạn là ai - nhưng bạn không có   quyền truy cập tài nguyên này. Có thể nếu bạn hỏi hệ thống   quản trị viên độc đáo, bạn sẽ được phép. Nhưng xin đừng bận tâm   tôi một lần nữa cho đến khi tình trạng khó khăn của bạn thay đổi. ”

Tóm lại, một 401 trái phép phản ứng nên được sử dụng để thiếu   hoặc xác thực không hợp lệ và 403 Cấm phản ứng 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.

Khác định dạng ảnh đẹp cách sử dụng mã trạng thái http.


2844
2017-08-04 06:24



Thông báo IIS 403 mặc định là "Đây là lỗi 403 chung và có nghĩa là người dùng được xác thực không được phép xem trang", điều này dường như đồng ý. - Ben Challenor
@JPReddy Câu trả lời của bạn là chính xác. Tuy nhiên, tôi hy vọng rằng 401 sẽ được đặt tên là "Unauthenticated" và 403 sẽ được đặt tên là "Unauthorized". Nó là rất khó hiểu rằng 401, mà đã làm với xác thực, có định dạng kèm theo văn bản "trái phép" .... Trừ khi tôi không tốt bằng tiếng Anh (đó là khá một khả năng). - p.matsinopoulos
@ ZaidMasud, theo RFC giải thích này là không chính xác. Câu trả lời của Cumbayah đã đúng. 401 có nghĩa là "bạn đang thiếu quyền ủy quyền". Nó ngụ ý "nếu bạn muốn bạn có thể thử xác thực bản thân". Vì vậy, cả khách hàng không xác thực chính xác và khách hàng được xác thực bị thiếu ủy quyền sẽ nhận được 401. 403 có nghĩa là "Tôi sẽ không trả lời câu hỏi này cho dù bạn là ai". RFC nêu rõ rằng "ủy quyền sẽ không giúp được" trong trường hợp 403. - Davide R.
401 là lỗi xác thực, 403 là lỗi ủy quyền. Đơn giản như thế. - Shahriyar Imanov
Bạn đã bỏ qua "Vâng đó là quan điểm của tôi về nó anyway :)" khi sao chép từ bài đăng trên blog của mình và tiếc là quan điểm của anh ấy là sai. Như những người khác đã tuyên bố 403 có nghĩa là bạn không thể truy cập tài nguyên bất kể bạn được xác thực là ai. Tôi thường sử dụng mã trạng thái này cho các tài nguyên bị khóa bởi phạm vi địa chỉ IP hoặc tệp trong webroot của tôi mà tôi không muốn truy cập trực tiếp (tức là tập lệnh phải phân phối chúng). - Kyle


Xem RFC2616:

401 Trái phép:

Nếu yêu cầu đã bao gồm thông tin đăng nhập Ủ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 đăng nhập đó.

403 Cấm:

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

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, hãy xem RFC7231 và RFC7235.


336
2017-07-21 07:28



Cảm ơn, điều đó đã giúp làm rõ điều đó cho tôi. Tôi đang sử dụng cả hai - 401 cho người dùng chưa được xác thực, 403 đối với người dùng được xác thực với đủ quyền. - VirtuosiMedia
Tôi đã không downvote nhưng tôi tìm thấy câu trả lời này khá gây hiểu lầm. 403 bị cấm được sử dụng hợp lý hơn trong nội dung sẽ không bao giờ được phân phối (như tệp .config trong asp.net). của nó hoặc là một 404. imho, nó sẽ không được thích hợp để trả lại 403 cho một cái gì đó có thể được truy cập nhưng bạn chỉ không có các thông tin đúng. giải pháp của tôi là cung cấp thông báo bị từ chối truy cập với cách thay đổi thông tin đăng nhập. đó hoặc 401. - Mel
"Câu trả lời PHẢI bao gồm trường tiêu đề WWW-Authenticate (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." Dường như nếu bạn không muốn sử dụng xác thực kiểu HTTP, mã phản hồi 401 không thích hợp. - Brilliand
Tôi sẽ trở lại Billiand ở đây. Câu lệnh là "Nếu yêu cầu đã bao gồm thông tin đăng nhập ủy quyền". Điều đó có nghĩa là nếu đây là phản hồi từ yêu cầu cung cấp thông tin xác thực (ví dụ: phản hồi từ lần xác thực RFC2617). Về cơ bản, nó cho phép máy chủ nói, "Cặp tài khoản / mật khẩu không hợp lệ, hãy thử lại". Trong câu hỏi đặt ra, người dùng có lẽ được xác thực nhưng không được ủy quyền. 401 không bao giờ là câu trả lời thích hợp cho những trường hợp đó. - ldrut
Brilliand đúng, 401 chỉ thích hợp cho Xác thực HTTP. - Juampi


Một số câu trả lời khác bị thiếu là nó phải được hiểu rằng Xác thực và ủy quyền trong ngữ cảnh RFC 2616 chỉ CHỈ cho giao thức Xác thực HTTP của RFC 2617. Xác thực bằng lược đồ 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 có sử dụng 401 hoặc 403 hay không.

Tóm tắt và Terse

Trái 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. Bị cấm chỉ ra rằng máy khách được RFC2617 xác thực và không có 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 bạn và không bao giờ sử dụng Xác thực HTTP, 403 luôn là câu trả lời đúng và 401 sẽ không bao giờ được sử dụng.

Chi tiết và độ sâu

Từ RFC2616

10.4.2 401 trái phép

Yêu cầu yêu cầu xác thực người dùng. Câu trả lời PHẢI bao gồm trường tiêu đề WWW-Authenticate (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. Khách hàng CÓ THỂ lặp lại yêu cầu với trường tiêu đề Ủy quyền thích hợp (mục 14.8).

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

Điều đầu tiên cần lưu ý là "Xác thực" và "Ủy quyền" trong ngữ cảnh của tài liệu này chỉ cụ thể cho 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 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" để tham khảo xác thực và ủy quyền bằng các phương thức khác với RFC2617

Vì vậy, sự khác biệt thực sự không phải là vấn đề là gì hay 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 máy khách thực hiện tiếp theo.

401 cho biết rằng tài nguyên không thể được cung cấp, nhưng máy chủ đang YÊU CẦU rằng khách hàng đăng nhập thông qua Xác thực HTTP và đã gửi tiêu đề trả lời để bắt đầu quá trình. Có thể có các ủy quyền cho phép truy cập vào tài nguyên, có thể không có, nhưng hãy thử xem và 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à có, cho 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ó vấn đề gì khi cố gắng. Điều này có thể bởi vì nó được biết rằng không có mức độ xác thực là đủ (ví dụ vì một danh sách đen IP), nhưng nó 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 xác thực để trường hợp người dùng có thể có một bộ thông tin đăng nhập thứ hai có thể được ủy quyền có thể bị bỏ qua. Nó không gợi ý cũng không ngụ ý rằng một số loại trang đăng nhập hoặc giao thức xác thực không RFC2617 khác có thể hoặc không thể giúp - đó là ngoài các tiêu chuẩn và định nghĩa của RFC2616.


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


254
2018-02-05 17:14



IMHO, đây là câu trả lời chính xác nhất và tốt nhất. - Juampi
Vậy chúng ta nên làm gì khi người dùng yêu cầu trang yêu cầu xác thực không phải http? Gửi mã trạng thái 403? - marcovtwout
Đây là câu trả lời đã trả lời các câu hỏi của tôi về sự khác biệt. - Patrick
Điều này quan trọng: "nếu bạn có quy trình đăng nhập của riêng bạn và không bao giờ sử dụng Xác thực HTTP, 403 luôn là câu trả lời đúng và 401 sẽ không bao giờ được sử dụng". - ggg
Không RFC7235 cung cấp cho "thử nghiệm của riêng bạn" hoặc thử thách auth thay thế? Tại sao luồng đăng nhập của ứng dụng của tôi không thể hiện ra thách thức của nó dưới dạng một WWW-Authenticate tiêu đề? Ngay cả khi một trình duyệt không hỗ trợ nó, ứng dụng React của tôi có thể ... - jchook


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 yêu cầu đó. Ủy quyền sẽ không giúp và yêu cầu KHÔNG được lặp lại. Nếu phương thức yêu cầu không phải là HEAD và máy chủ muốn công khai vì sao yêu cầu chưa được thực hiện, nó 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, bạn có thể sử dụng mã trạng thái 404 (Không tìm thấy) để thay thế

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


95
2017-07-21 07:26



Và nếu nó không rõ ràng nếu họ có thể truy cập hay không? Giả sử tôi có 3 cấp độ người dùng - Công khai, Thành viên và Thành viên cao cấp. Giả sử rằng trang chỉ dành cho Thành viên cao cấp. Người dùng công khai về cơ bản chưa được xác thực và có thể là thành viên hoặc thành viên Premium khi họ đăng nhập. Đối với cấp độ thành viên, 403 có vẻ phù hợp. Đối với các thành viên Premium, 401. Tuy nhiên, bạn phục vụ công cộng những gì? - VirtuosiMedia
imho, đây là câu trả lời chính xác nhất. nó phụ thuộc vào ứng dụng nhưng nói chung, nếu người dùng được xác thực không có đủ quyền đối với tài nguyên, bạn có thể muốn cung cấp cách thay đổi bằng chứng xác thực hoặc gửi 401. Tôi nghĩ 403 phù hợp nhất với nội dung không bao giờ được phân phát. Trong asp.net, điều này có nghĩa là tệp web.config * .resx tệp vv vì không có vấn đề gì người dùng đăng nhập, những tệp này sẽ KHÔNG BAO GIỜ được phục vụ nên không có điểm nào trong thử lại. - Mel
Câu trả lời này xứng đáng có nhiều upvotes hơn. Tôi đồng ý với @Mel. - Camilo Martin
1, nhưng không chắc chắn +1. Kết luận hợp lý là 403 sẽ không bao giờ được trả về như 401 hoặc 404 sẽ là một phản ứng tốt hơn. - CurtainDog
@ Tôi nghĩ rằng một tập tin mà không nên được truy cập bởi khách hàng nên là một 404. Đó là một tập tin đó là nội bộ cho hệ thống; bên ngoài thậm chí không biết nó tồn tại. Bằng cách trả lại 403 bạn đang cho phép khách hàng biết nó tồn tại, không cần phải cung cấp thông tin đó cho tin tặc. Thông số cho 403 nói An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found). - Juan Mendes


Phiên bản TL; DR

    GET tài nguyên, tồn tại?
    | |
    | |
    v v
KHÔNG: 404 CÓ: Được chứng thực?
             | |
             | |
             v v
           NO: 401 YES: Có thể truy cập tài nguyên không?
           (hoặc: 404) | |
           hoặc 301 | |
           chuyển hướng v v
           để đăng nhập NO: 403 OK 200, 301, ...

Séc thường được thực hiện theo thứ tự sau:

  • 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
  • 404 nếu tài nguyên không tồn tại

KHÔNG ĐƯỢC PHÉP: Mã trạng thái (401) cho biết rằng yêu cầu yêu cầu xác thực. Người dùng / đại lý không xác định bởi máy chủ. Có thể lặp lại với các thông tin đăng nhập khác. LƯU Ý: Điều này là khó hiểu 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'.

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 nhưng đã thiếu thông tin đăng nhập. Yêu cầu lặp lại sẽ không hoạt động.

KHÔNG TÌM THẤY: 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 đã biết nhưng máy chủ sẽ không tiết lộ bất cứ điều gì về tài nguyên, thực hiện như thể nó không tồn tại. Lặp lại sẽ không hoạt động. Đây là một đặc biệt sử dụng 404 (ví dụ như github).


46
2018-02-23 11:00



github.com/for-GET/http-decision-diagram - Christophe Roussy
Ví dụ tôi đã đăng nhập và tôi có thể truy cập một trang nhưng nó không được phép cho phép tôi. Mã trạng thái nào sẽ trả lại? - barteloma
@bookmarker Loggin được gọi là xác thực, đó là bước đầu tiên. Vì vậy, nếu bạn không có quyền sau khi đăng nhập, bạn sẽ nhận được 403 Cấm (không đủ thông tin xác thực nghĩa là bạn không có đủ quyền). - Christophe Roussy
Rõ ràng và giải thích đơn giản. Chỉ cần những gì tôi cần. - Estevez


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ì 401 trái phép phải được trả lại. 403 Cấm được sử dụng chủ yếu khi truy cập vào tài nguyên bị cấm cho tất cả mọi người hoặc bị giới hạn vào một mạng nhất định hoặc chỉ được phép qua SSL, bất kể miễn là nó không liên quan đến xác thực.

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

Và đây là từ RFC 2616:

10.4.4 403 bị cấm

Máy chủ đã hiểu yêu cầu, nhưng từ chối thực hiện yêu cầu đó.
Ủy quyền sẽ không giúp và yêu cầu KHÔNG được lặp lại.
  Nếu phương thức yêu cầu không phải là HEAD và máy chủ muốn thực hiện
  công khai tại sao yêu cầu chưa được hoàn thành, nó 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ế.

Chỉnh sửa: 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) cho biết rằng máy chủ   đã hiểu yêu cầu nhưng từ chối cho phép. Một máy chủ   mong muốn công khai tại sao yêu cầu bị cấm   mô tả lý do đó trong trọng tải đáp ứng (nếu có).

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

Máy chủ gốc muốn "ẩn" sự tồn tại hiện tại của
  tài nguyên mục tiêu bị cấm CÓ THỂ trả lời bằng mã trạng thái của
  404 không tìm thấy).

Như vậy, 403 bây giờ có thể có ý nghĩa 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.


37
2018-02-27 09:44



Hay đấy. Dựa trên RFC 7231 và RFC 7235, tôi không thấy sự khác biệt rõ ràng giữa 401 và 403 - Brian
403 có nghĩa là "Tôi biết bạn nhưng bạn không thể thấy tài nguyên này". Không có lý do gì để nhầm lẫn. - Michael Blackburn
"Nếu yêu cầu bao gồm thông tin xác thực 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 đăng nhập đó. Khách hàng CÓ THỂ lặp lại yêu cầu với trường tiêu đề Cấp phép mới hoặc thay thế (Phần 4.1)." Tuy nhiên, sau đó "4.2. Trường tiêu đề 'Ủy quyền' cho phép tác nhân người dùng xác thực chính nó bằng máy chủ gốc". Có vẻ như trong RFC7235, họ sử dụng thuật ngữ "ủy quyền" giống như "xác thực". Trong trường hợp đó, có vẻ như một người dùng được xác thực nhưng không được ủy quyền không được nhận 401, mà đúng hơn là 403 - arcuri82


Đây là một câu hỏi cũ hơn, nhưng một tùy chọn không 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ỏ phiếu cao nhất bị một tiềm năng lỗ hổng rò rỉ thông tin. Ví dụ: giả sử trang web bảo mật được đề cập là trang quản trị hệ thống hoặc có lẽ thường là 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 / hồ sơ ở đó, hãy để một mình rằng 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 / không được ủy quyền trong nhật ký nội bộ, nhưng trả về 404.

OWASP có một số thêm thông tin về việc 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.


20
2017-12-25 09:09



Việc sử dụng 404 đã được đề cập trong các câu trả lời trước. Bạn đang trên điểm tái: rò rỉ thông tin và điều này nên là một xem xét quan trọng cho bất cứ ai lăn riêng của họ xác thực / ủy quyền chương trình. +1 để đề cập đến OWASP. - Dave Watts


Câu hỏi này đã được hỏi một số thời gian trước đây, nhưng suy nghĩ của người dân di chuyển trên.

Phần 6.5.3 trong bản nháp này (tác giả của Fielding và Reschke) cung cấp mã trạng thái 403 có ý nghĩa hơi khác với ý nghĩa được viết trong RFC 2616.

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

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

6.5.3. 403 Cấm

Mã trạng thái 403 (Bị cấm) cho biết máy chủ đã hiểu yêu cầu nhưng từ chối cho phép. Một máy chủ muốn công khai 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 xác thực được cung cấp trong yêu cầu, máy chủ xem 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 đăng nhập mới hoặc khác.  Tuy nhiên, yêu cầu có thể bị cấm vì lý do không liên quan đến thông tin đăng nhập.

Máy chủ gốc muốn "ẩn" sự tồn tại hiện tại của tài nguyên mục tiêu bị cấm CÓ THỂ thay vào đó 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.


19
2018-05-22 10:54



Dự thảo đã được phê duyệt và hiện là RFC 7231. - Vebjorn Ljosa


TL; DR

  • 401: Từ chối liên quan đến xác thực
  • 403: Việc từ chối KHÔNG có 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ẽ trả lời bằng 401 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 403 Forbidden

RFC (2616 Phần 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 đăng nhập Ủ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 đă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 ...

Biết thêm chi tiết:

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

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

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

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


9
2018-02-25 09:03