존재하지만 사용자에게 충분한 권한이 없는 웹 페이지의 경우(로그인되지 않았거나 적절한 사용자 그룹에 속하지 않음) 제공할 적절한 HTTP 응답은 무엇입니까?
401 Unauthorized 없습니까?
403 Forbidden ?
다른 것?
지금까지 각각에 대해 읽은 내용은 둘의 차이점에 대해 명확하지 않습니다. 각 응답에 적합한 사용 사례는 무엇입니까?
반응형
질문자 :VirtuosiMedia
Daniel Irvine 의 명확한 설명:
인증 오류에 대한 HTTP 상태 코드인 401 Unauthorized에 문제가 있습니다. 그리고 그게 전부입니다. 인증이 아니라 인증을 위한 것입니다. 401 응답을 수신하면 서버에서 "인증되지 않았습니다. 전혀 인증되지 않았거나 잘못 인증되었습니다. 그러나 다시 인증하고 다시 시도하십시오."라고 말합니다. 도움이 되도록 인증 방법을 설명하는 WWW-Authenticate 헤더가 항상 포함됩니다.
이것은 일반적으로 웹 애플리케이션이 아니라 웹 서버에서 반환되는 응답입니다.
그것은 또한 매우 일시적인 것입니다. 서버에서 다시 시도하도록 요청합니다.
따라서 승인을 위해 403 Forbidden 응답을 사용합니다. 영구적이고 내 응용 프로그램 논리와 연결되어 있으며 401보다 더 구체적인 응답입니다.
403 응답을 받으면 서버에서 "죄송합니다. 나는 당신이 누구인지 압니다. 당신이 누구인지 믿습니다. 하지만 당신은 이 자원에 접근할 권한이 없습니다. 시스템 관리자에게 잘 물어보면 허락을 받을지도 모릅니다. 하지만 당신의 곤경이 바뀔 때까지 다시는 저를 괴롭히지 마십시오.”
요약하면, 인증이 누락되었거나 잘못된 경우에는 401 Unauthorized 응답을 사용해야 하며, 사용자가 인증되었지만 지정된 리소스에 대해 요청된 작업을 수행할 권한이 없는 경우 나중에 403 Forbidden 응답을 사용해야 합니다.
http 상태 코드를 사용하는 방법에 대한 또 다른 멋진 그림 형식입니다.
JPReddy
편집: RFC2616 은 더 이상 사용되지 않습니다( RFC7231 및 RFC7235 참조).
401 무단:
요청에 이미 권한 부여 자격 증명이 포함된 경우 401 응답은 해당 자격 증명에 대한 권한 부여가 거부되었음을 나타냅니다.
403 금지:
서버가 요청을 이해했지만 이행을 거부합니다.
사용 사례에서 사용자가 인증되지 않은 것으로 보입니다. 나는 401을 반환할 것이다.
Oded
다른 답변이 누락된 것은 RFC 2616 컨텍스트의 인증 및 권한 부여가 RFC 2617의 HTTP 인증 프로토콜만 참조한다는 점을 이해해야 한다는 것입니다. RFC2617 외부 체계에 의한 인증은 HTTP 상태 코드에서 지원되지 않으며 고려되지 않습니다. 401을 사용할지 403을 사용할지 결정할 때
간략하고 간결
Unauthorized는 클라이언트가 RFC2617 인증을 받지 않았으며 서버가 인증 프로세스를 시작하고 있음을 나타냅니다. Forbidden은 클라이언트가 RFC2617 인증을 받았고 권한이 없거나 서버가 요청된 리소스에 대해 RFC2617을 지원하지 않음을 나타냅니다.
즉, 자체 로그인 프로세스가 있고 HTTP 인증을 사용하지 않는 경우 403이 항상 적절한 응답이며 401을 사용해서는 안 됩니다.
상세하고 깊이 있는
RFC2616에서
10.4.2 401 승인되지 않음
요청에는 사용자 인증이 필요합니다. 응답은 요청된 리소스에 적용 가능한 챌린지를 포함하는 WWW-Authenticate 헤더 필드(섹션 14.47)를 포함해야 합니다(MUST). 클라이언트는 적절한 Authorization 헤더 필드(섹션 14.8)를 사용하여 요청을 반복할 수 있습니다(MAY).
그리고
10.4.4 403 금지됨 서버가 요청을 이해했지만 이행을 거부합니다. 승인은 도움이 되지 않으며 요청을 반복해서는 안 됩니다(SHOULD NOT).
명심해야 할 첫 번째 사항은 이 문서의 컨텍스트에서 "인증" 및 "권한 부여"가 특히 RFC 2617의 HTTP 인증 프로토콜을 참조한다는 것입니다. 이들은 사용자가 생성했을 수 있는 자체 인증 프로토콜을 참조하지 않습니다. 로그인 페이지 등을 사용합니다. RFC2617 이외의 방법에 의한 인증 및 권한 부여를 참조하기 위해 "로그인"을 사용합니다.
따라서 진정한 차이점은 문제가 무엇인지 또는 솔루션이 있는지 여부가 아닙니다. 차이점은 서버가 클라이언트가 다음에 수행할 것으로 기대하는 것입니다.
401은 리소스를 제공할 수 없음을 나타내지만 서버는 클라이언트가 HTTP 인증을 통해 로그인하도록 요청하고 프로세스를 시작하기 위해 응답 헤더를 보냈습니다. 리소스에 대한 액세스를 허용하는 권한 부여가 있을 수 있지만 없을 수도 있지만 시도해보고 어떤 일이 발생하는지 보겠습니다.
403은 리소스를 제공할 수 없고 현재 사용자가 RFC2617을 통해 이를 해결할 방법이 없으며 시도할 필요도 없음을 나타냅니다. 이는 인증 수준이 충분하지 않다는 것이 알려져 있기 때문일 수 있지만(예: IP 블랙리스트 때문에) 사용자가 이미 인증되었고 권한이 없기 때문일 수 있습니다. RFC2617 모델은 단일 사용자, 단일 자격 증명이므로 사용자가 승인될 수 있는 두 번째 자격 증명 세트를 가질 수 있는 경우는 무시될 수 있습니다. 그것은 어떤 종류의 로그인 페이지나 기타 비RFC2617 인증 프로토콜이 도움이 될 수도 있고 도움이 되지 않을 수도 있다는 것을 암시하거나 암시하지 않습니다. 즉, RFC2616 표준 및 정의를 벗어납니다.
ldrut
+-----------------------
| 자원이 있습니까? (비공개인 경우 종종 인증 확인 후 확인됨)
+-----------------------
| |
아니오 | v 예
v +--------------------------
404 | 로그인되어 있습니까? (인증된, 사용자 세션이라고도 함)
또는 +-----------------------
401 | |
403 아니요 | | 예
3xx vv
401 +-----------------------
(404 공개 없음) | 리소스에 액세스할 수 있습니까? (허가, 승인, ...)
또는 +-----------------------
리디렉션 | |
로그인하려면 NO | | 예
| |
vv
403 확인 200, 리디렉션, ...
(또는 404: 공개 안 함)
(또는 404: 비공개인 경우 리소스가 존재하지 않음)
(또는 3xx: 리디렉션)
검사는 일반적으로 다음 순서로 수행됩니다.
- 리소스가 공용이고 존재하지 않는 경우 404 또는 3xx 리디렉션
- 그렇지 않으면:
- 401 로그인하지 않았거나 세션이 만료된 경우
- 사용자가 리소스(파일, json, ...)에 액세스할 수 있는 권한이 없는 경우 403
- 404 리소스가 존재하지 않거나 아무 것도 공개하지 않으려는 경우 또는 3xx 리디렉션
UNAUTHORIZED : 요청에 인증 이 필요함을 나타내는 상태 코드(401) , 일반적으로 이것은 사용자가 로그인(세션)해야 함을 의미합니다. 서버에서 알 수 없는 사용자/에이전트입니다. 다른 자격 증명으로 반복할 수 있습니다. 참고: 이것은 '인증되지 않음' 대신 '인증되지 않음'으로 이름을 지정해야 하기 때문에 혼란스럽습니다. 세션이 만료된 경우 로그인 후에도 발생할 수 있습니다. 특별한 경우: 404 대신 사용 하여 리소스의 존재 여부를 표시하지 않을 수 있습니다(크레딧 @gingerCodeNinja).
FORBIDDEN : 서버가 요청을 이해했지만 이행을 거부했음을 나타내는 상태 코드(403)입니다. 서버에서 알고 있는 사용자/에이전트이지만 자격 증명이 충분하지 않습니다 . 자격 증명이 변경되지 않는 한 반복 요청은 작동하지 않습니다. 이는 단기간에 거의 발생하지 않습니다. 특별한 경우: 리소스의 존재를 드러내는 것이 민감한 데이터를 노출시키거나 공격자에게 유용한 정보를 제공하는 경우 리소스의 존재 여부를 밝히지 않기 위해 404 대신 사용할 수 있습니다(@gingerCodeNinja 크레딧).
NOT FOUND : 요청된 리소스를 사용할 수 없음을 나타내는 상태 코드(404)입니다. 사용자/에이전트는 알려져 있지만 서버는 리소스에 대해 아무 것도 공개하지 않으며 마치 존재하지 않는 것처럼 합니다. 반복하면 작동하지 않습니다. 이것은 404의 특별한 용도입니다(예를 들어 github에서 수행).
@ChrisH가 언급했듯이 리디렉션 3xx (301, 302, 303, 307 또는 리디렉션하지 않고 401 사용)에 대한 몇 가지 옵션이 있습니다.
Christophe Roussy
RFC 2616 (HTTP/1.1)에 따르면 403은 다음과 같은 경우에 전송됩니다.
서버가 요청을 이해했지만 이행을 거부합니다. 승인은 도움이 되지 않으며 요청을 반복해서는 안 됩니다(SHOULD NOT). 요청 방법이 HEAD가 아니고 서버가 요청이 이행되지 않은 이유를 공개하려는 경우 엔티티에서 거부 이유를 설명해야 합니다(SHOULD). 서버가 이 정보를 클라이언트가 사용할 수 있도록 하지 않으려면 상태 코드 404(찾을 수 없음)를 대신 사용할 수 있습니다.
즉, 클라이언트가 인증을 통해 리소스에 액세스할 수 있으면 401을 보내야 합니다.
Cumbayah
HTTP 인증 ( WWW-Authenticate 및 Authorization 헤더) 이 사용 중이라고 가정하고 다른 사용자로 인증하면 요청된 리소스에 대한 액세스 권한이 부여되면 401 Unauthorized가 반환되어야 합니다.
403 Forbidden은 HTTP 인증과 관련이 없는 한 리소스에 대한 액세스가 모든 사람에게 금지되거나 지정된 네트워크로 제한되거나 SSL을 통해서만 허용될 때 사용됩니다.
HTTP 인증이 사용되지 않고 서비스가 요즘 표준인 쿠키 기반 인증 체계를 가지고 있다면 403 또는 404가 반환되어야 합니다.
401과 관련하여 이것은 RFC 7235(Hypertext Transfer Protocol(HTTP/1.1): 인증) 에서 가져온 것입니다.
3.1. 401 권한 없음
401(Unauthorized) 상태 코드는 대상 리소스에 대한 유효한 인증 자격 증명이 부족하여 요청이 적용되지 않았음을 나타냅니다. 원 서버는 대상 리소스에 적용 가능한 적어도 하나의 챌린지를 포함 하는 WWW-Authenticate 헤더 필드(섹션 4.4)를 보내야 합니다(MUST). 요청에 인증 자격 증명이 포함된 경우 401 응답은 해당 자격 증명에 대한 권한 부여가 거부되었음을 나타냅니다 . 클라이언트는 새로운 또는 교체된 Authorization 헤더 필드(섹션 4.1)로 요청을 반복할 수 있습니다(MAY). 401 응답이 이전 응답과 동일한 시도를 포함하고 사용자 에이전트가 이미 한 번 이상 인증을 시도한 경우 사용자 에이전트는 일반적으로 관련 진단 정보를 포함하기 때문에 사용자에게 동봉된 표현을 제시해야 합니다(SHOULD).
403(및 404)의 의미는 시간이 지남에 따라 변경되었습니다. 이것은 1999년부터입니다( RFC 2616 ):
10.4.4 403 금지
서버가 요청을 이해했지만 이행을 거부합니다. 승인은 도움이 되지 않으며 요청을 반복해서는 안 됩니다(SHOULD NOT). 요청 방법이 HEAD가 아니고 서버가 요청이 이행되지 않은 이유를 공개하려는 경우 엔티티에서 거부 이유를 설명해야 합니다(SHOULD). 서버가 이 정보를 클라이언트에서 사용할 수 있도록 하지 않으려면 상태 코드 404(찾을 수 없음)를 대신 사용할 수 있습니다.
2014년 RFC 7231(Hypertext Transfer Protocol(HTTP/1.1): Semantics and Content) 은 403의 의미를 변경했습니다.
6.5.3. 403 금지
403(금지됨) 상태 코드는 서버가 요청을 이해했지만 승인을 거부했음을 나타냅니다. 요청이 금지된 이유를 공개하려는 서버는 응답 페이로드(있는 경우)에서 그 이유를 설명할 수 있습니다.
요청에 인증 자격 증명이 제공된 경우 서버는 액세스 권한을 부여하기에 충분하지 않은 것으로 간주합니다. 클라이언트는 동일한 자격 증명으로 요청을 자동으로 반복해서는 안 됩니다(SHOULD NOT). 클라이언트는 새 자격 증명이나 다른 자격 증명으로 요청을 반복할 수 있습니다(MAY). 그러나 자격 증명과 관련 없는 이유로 요청이 금지될 수 있습니다.
금지된 대상 리소스의 현재 존재를 "숨기기" 원하는 원 서버는 대신 상태 코드 404(찾을 수 없음)로 응답할 수 있습니다(MAY).
따라서 403(또는 404)은 이제 무엇이든 의미할 수 있습니다. 새 자격 증명을 제공하면 도움이 될 수도 있고 그렇지 않을 수도 있습니다.
이것이 변경된 이유는 RFC 2616이 실제로 오늘날의 웹 앱이 예를 들어 양식 및 쿠키를 사용하여 사용자 지정 인증 체계를 구축할 때 HTTP 인증이 사용된다고 가정했기 때문이라고 생각합니다.
Erwan Legrand
- 401 Unauthorized : 나는 당신이 누군지 모릅니다. 인증 오류입니다.
- 403 Forbidden : 당신이 누군지 알지만 당신은 이 자원에 접근할 수 있는 권한이 없습니다. 승인 오류입니다.
Akshay Misal
이것은 더 오래된 질문이지만 실제로 제기되지 않은 한 가지 옵션은 404를 반환하는 것이었습니다. 보안 관점에서 가장 많이 투표된 답변은 잠재적인 정보 유출 취약성으로 인해 어려움을 겪습니다. 예를 들어 문제의 보안 웹 페이지가 시스템 관리 페이지이거나 더 일반적으로 사용자가 액세스할 수 없는 시스템의 레코드라고 가정해 보겠습니다. 이상적으로는 악의적인 사용자가 액세스 권한이 없다는 것은 고사하고 페이지/레코드가 있다는 사실조차 알지 못하도록 하는 것이 좋습니다. 이와 같은 것을 구축할 때 내부 로그에 인증되지 않은/승인되지 않은 요청을 기록하려고 시도하지만 404를 반환합니다.
OWASP에는 공격자가 이러한 유형의 정보를 공격의 일부로 사용할 수 있는 방법에 대한 추가 정보가 있습니다.
Patrick White
이 질문은 얼마 전에 제기되었지만 사람들의 생각은 계속됩니다.
이 초안의 섹션 6.5.3 (Fielding 및 Reschke 작성)은 상태 코드 403에 RFC 2616에 문서화된 것과 약간 다른 의미를 부여합니다.
많은 인기 있는 웹 서버 및 프레임워크에서 사용하는 인증 및 권한 부여 체계에서 일어나는 일을 반영합니다.
가장 중요하다고 생각되는 부분을 강조했습니다.
6.5.3. 403 금지
403(금지됨) 상태 코드는 서버가 요청을 이해했지만 승인을 거부했음을 나타냅니다. 요청이 금지된 이유를 공개하려는 서버는 응답 페이로드(있는 경우)에서 그 이유를 설명할 수 있습니다.
요청에 인증 자격 증명이 제공된 경우 서버는 액세스 권한을 부여하기에 충분하지 않은 것으로 간주합니다. 클라이언트는 동일한 자격 증명으로 요청을 반복해서는 안 됩니다(SHOULD NOT). 클라이언트는 새 자격 증명이나 다른 자격 증명으로 요청을 반복할 수 있습니다(MAY). 그러나 자격 증명과 관련 없는 이유로 요청이 금지될 수 있습니다.
금지된 대상 리소스의 현재 존재를 "숨기기" 원하는 원 서버는 대신 상태 코드 404(찾을 수 없음)로 응답할 수 있습니다(MAY).
어떤 규칙을 사용하든 중요한 것은 사이트/API 전체에 균일성을 제공하는 것입니다.
Dave Watts
!!! DEPR: 대답은 2014년까지 일반적인 관행이었던 것을 반영합니다!!!
TL;DR
- 401: 인증과 관련된 거부
- 403: 인증과 무관한 거절
실제 사례
아파치 가 인증을 요구하고 .htaccess 를 통해 Cancel 를 누르면 401 Authorization Required 응답합니다.
nginx 가 파일을 찾았지만 파일을 읽거나 액세스할 수 있는 액세스 권한 403 Forbidden
RFC(2616 섹션 10)
401 무단(10.4.2)
의미 1: 인증 필요
요청에는 사용자 인증이 필요합니다. ...
의미 2: 인증 부족
... 요청에 이미 인증 자격 증명이 포함된 경우 401 응답은 해당 자격 증명에 대한 인증이 거부되었음을 나타냅니다. ...
403 금지된 (10.4.4)
의미: 인증과 관련 없음
... 승인이 도움이되지 않습니다 ...
자세한 내용은:
서버가 요청을 이해했지만 이행을 거부합니다.
엔터티에서 거부 이유를 설명해야 합니다(SHOULD).
대신 상태 코드 404(찾을 수 없음)를 사용할 수 있습니다.
(서버가 클라이언트로부터 이 정보를 유지하려는 경우)
Levite
로그인하지 않았거나 적절한 사용자 그룹에 속하지 않았습니다.
당신은 두 가지 다른 경우를 언급했습니다. 각 경우에 다른 응답이 있어야 합니다.
- 그들이 전혀 로그인하지 않은 경우 401 Unauthorized를 반환해야 합니다.
- 로그인했지만 적절한 사용자 그룹에 속하지 않은 경우 403 Forbidden을 반환해야 합니다.
이 답변에 대한 의견을 기반으로 한 RFC에 대한 참고 사항:
사용자가 로그인하지 않은 경우 인증되지 않은 것입니다. 이에 해당하는 HTTP는 401이고 RFC에서 오해의 소지가 있는 Unauthorized라고 합니다. 섹션 10.4.2 에서 401 Unauthorized :
"요청에 사용자 인증이 필요합니다."
인증되지 않은 경우 401이 정답입니다. 그러나 권한이 없는 경우 의미상 올바른 의미에서 403이 올바른 응답입니다.
Zaid Masud
의미는 다음과 같습니다.
401 : 사용자가 (올바르게) 인증되지 않음, 리소스/페이지에 인증이 필요합니다.
403 : 사용자의 역할 또는 권한이 요청된 리소스에 대한 액세스를 허용하지 않습니다. 예를 들어 사용자는 관리자가 아니며 요청된 페이지는 관리자용입니다.
참고 : 기술적으로 403은 401의 상위 집합입니다. 인증되지 않은 사용자에게도 403을 제공하는 것이 합법이기 때문입니다. 어쨌든 구별하는 것이 더 의미가 있습니다.
Luca C.
영어로:
401
귀하는 잠재적으로 액세스가 허용되지만 이 요청에 대해 어떤 이유로 인해 거부되었습니다. 나쁜 암호와 같은? 다시 시도하십시오. 올바른 요청으로 대신 성공 응답을 받게 됩니다.
403
당신은 절대 허용되지 않습니다. 당신의 이름은 목록에 없습니다, 당신은 결코 들어가지 않을 것입니다, 가십시오, 재시도 요청을 보내지 마십시오, 그것은 항상 거절될 것입니다. 저리가요.
James
이것은 여기 어느 곳보다 내 머리에 더 간단합니다.
401: 이것을 보려면 HTTP 기본 인증이 필요합니다.
403: 이것을 볼 수 없으며 HTTP 기본 인증이 도움이 되지 않습니다.
사용자가 사이트의 표준 HTML 로그인 양식을 사용하여 로그인해야 하는 경우 401은 HTTP 기본 인증에만 해당되므로 적절하지 않습니다.
/includes 와 같은 항목에 대한 액세스를 거부하는 것은 권장하지 않습니다. 웹에 관한 한 이러한 리소스는 전혀 존재하지 않으므로 404여야 하기 때문입니다.
이렇게 하면 403이 "로그인해야 합니다"로 남습니다.
즉, 403은 "이 리소스에는 HTTP 기본 인증이 아닌 다른 형식의 인증이 필요합니다"라는 의미입니다.
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2
Vladimir Kornea
브라우저에서 401은 사용자가 새 자격 증명을 입력할 수 있도록 인증 대화 상자를 시작하지만 403은 그렇지 않다는 점을 고려하는 것이 중요하다고 생각합니다. 브라우저는 401이 반환되면 사용자가 다시 인증해야 한다고 생각합니다. 따라서 401은 잘못된 인증을 나타내고 403은 권한 부족을 나타냅니다.
다음은 인증 또는 권한 부여에서 오류가 반환되는 논리에 따라 중요한 문구가 굵게 표시되는 몇 가지 경우입니다.
- 리소스에 인증이 필요하지만 자격 증명 이 지정 되지 않았습니다.
401 : 클라이언트가 자격 증명을 지정해야 합니다.
- 지정된 자격 증명의 형식이 잘못되었습니다 .
400 : 구문 오류는 항상 400을 반환해야 하므로 401도 403도 아닙니다.
- 지정된 자격 증명 이 존재하지 않는 사용자 를 참조합니다.
401 : 클라이언트가 유효한 자격 증명을 지정해야 합니다.
- 지정된 자격 증명 이 유효하지 않지만 유효한 사용자를 지정합니다(또는 지정된 사용자가 필요하지 않은 경우 사용자를 지정하지 않음).
401 : 다시, 클라이언트는 유효한 자격 증명을 지정해야 합니다.
- 지정된 자격 증명 이 만료되었습니다 .
401 : 이것은 일반적으로 유효하지 않은 자격 증명을 갖는 것과 실질적으로 동일하므로 클라이언트는 유효한 자격 증명을 지정해야 합니다.
- 지정된 자격 증명은 완전히 유효하지만 더 많은 권한이 있는 자격 증명이 있을 수 있지만 특정 리소스로 충분하지 않습니다.
403 : 현재 자격 증명이 이미 유효하지만 권한만 있기 때문에 유효한 자격 증명을 지정하면 리소스에 대한 액세스 권한이 부여되지 않습니다.
- 자격 증명에 관계없이 특정 리소스 에 액세스할 수 없습니다.
403 : 이것은 자격 증명과 관계가 없으므로 유효한 자격 증명을 지정해도 도움이 되지 않습니다.
- 지정된 자격 증명은 완전히 유효하지만 특정 클라이언트 는 자격 증명을 사용하지 못하도록 차단됩니다.
403 : 클라이언트가 차단된 경우 새 자격 증명을 지정해도 아무 작업도 수행되지 않습니다.
Grant Gryczan
문제( 7231 및 7235 )에 대한 최신 RFC를 감안할 때 사용 사례는 매우 명확해 보입니다(이탤릭체 추가).
- 401은 인증되지 않은 경우 ("유효한 인증이 없음")입니다. 즉 '나는 당신이 누구인지 모르거나 당신이 말하는 당신이 누구인지 믿지 않습니다.'
401 권한 없음
401(Unauthorized) 상태 코드는 대상 리소스에 대한 유효한 인증 자격 증명이 부족하여 요청이 적용되지 않았음을 나타냅니다. 401 응답을 생성하는 서버는 대상 리소스에 적용 가능한 적어도 하나의 챌린지를 포함하는 WWW-Authenticate 헤더 필드(섹션 4.1)를 보내야 합니다(MUST).
요청에 인증 자격 증명이 포함된 경우 401 응답은 해당 자격 증명에 대한 권한 부여가 거부되었음을 나타냅니다. 사용자 에이전트는 새로운 또는 교체된 Authorization 헤더 필드(섹션 4.2)로 요청을 반복할 수 있습니다(MAY). 401 응답이 이전 응답과 동일한 시도를 포함하고 사용자 에이전트가 이미 한 번 이상 인증을 시도한 경우 사용자 에이전트는 일반적으로 관련 진단 정보를 포함하기 때문에 사용자에게 동봉된 표현을 제시해야 합니다(SHOULD).
- 403은 무단 ("승인 거부")을 위한 것입니다. 즉, '나는 당신이 누군지 알지만 당신은 이 자원에 접근할 수 있는 권한이 없습니다.'
403 금지
403(금지됨) 상태 코드는 서버가 요청을 이해했지만 승인을 거부 했음을 나타냅니다. 요청이 금지된 이유를 공개하려는 서버는 응답 페이로드(있는 경우)에서 그 이유를 설명할 수 있습니다.
요청에 인증 자격 증명이 제공된 경우 서버는 액세스 권한을 부여하기에 충분하지 않은 것으로 간주합니다. 클라이언트는 동일한 자격 증명으로 요청을 자동으로 반복해서는 안 됩니다(SHOULD NOT). 클라이언트는 새 자격 증명이나 다른 자격 증명으로 요청을 반복할 수 있습니다(MAY). 그러나 자격 증명과 관련 없는 이유로 요청이 금지될 수 있습니다.
금지된 대상 리소스의 현재 존재를 "숨기기" 원하는 원 서버는 대신 상태 코드 404(찾을 수 없음)로 응답할 수 있습니다(MAY).
cjbarth
401 대 403의 경우 여러 번 답변했습니다. 이것은 본질적으로 '애플리케이션' 토론이 아니라 'HTTP 요청 환경' 토론입니다.
자체 로그인 문제(응용 프로그램)에 대한 질문이 있는 것 같습니다.
이 경우 HTTP Auth 대 로그인 페이지(HTTP Auth 설정에 연결되지 않음)를 사용하지 않는 한 단순히 로그인하지 않는 것만으로는 401 또는 403을 전송하기에 충분하지 않습니다. 파일에 대한 애플리케이션 수준 액세스를 위해 (요청된 리소스 대신) 자체 로그인 화면이 있는 "201 Created"를 찾고 있는 것 같습니다. 이것은 말한다:
"여기에 있다고 들었지만 대신 이것을 시도하십시오 (당신은 그것을 볼 수 없습니다)"
Shawn
출처 : http:www.stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses
반응형
'etc. > StackOverFlow' 카테고리의 다른 글
| 사전에 새 키를 추가하려면 어떻게 해야 합니까? (0) | 2021.10.27 |
|---|---|
| SQLite의 초당 INSERT 성능 향상 (0) | 2021.10.27 |
| 파이썬에서 어떻게 시간 지연(time sleep)을 할 수 있습니까? [duplicate] (0) | 2021.10.27 |
| 할당 후 예기치 않은 변경 사항을 나열합니다. 이것은 왜 발생하며 어떻게 방지할 수 있습니까? (0) | 2021.10.27 |
| 한 줄에 ArrayList 초기화 (0) | 2021.10.27 |