403 금지 된 vs 401 무단 HTTP 응답
질문
존재하는 웹 페이지의 경우 사용자가 충분한 권한이없는 경우 (로그인하지 않은 사용자 그룹에 속하지 않거나 적절한 사용자 그룹에 속하지 않음), 봉사 할 적절한 HTTP 응답은 무엇입니까?
401 무단? 403 금지? 다른 것?
지금까지 각각 읽은 것은 두 사람의 차이점에 대해 매우 분명하지 않습니다.어떤 이용 사례가 각 응답에 적합합니까?
답변
Daniel Irvine의 명확한 설명 :
인증 오류를위한 HTTP 상태 코드 인 401 권한이없는 문제가 있습니다. 그리고 그것은 단지 그것입니다. 그것은 인증이 아닌 인증을위한 것입니다. 401 응답을받는 것은 서버가 당신에게 말하고 있습니다. " 인증 - 전혀 인증되지 않았거나 인증되지 않았습니다 잘못되었지만 다시 인증하고 다시 시도하십시오. " 너를 돕기 위해, 항상 WWW 인증 헤더를 포함하여 방법을 설명합니다. 인증하려면. 이것은 일반적으로 귀하의 웹이 아닌 웹 서버에서 반환하는 응답입니다. 애플리케이션. 그것은 또한 매우 일시적인 것입니다. 서버가 당신에게 시도하도록 요청하고 있습니다 다시. 따라서 권한 부여는 403 개의 금단 대응을 사용합니다. 그것의 영구적 인, 그것은 내 응용 프로그램 논리에 묶여 있으며 더 구체적인 것입니다. 401보다 응답. 403 응답을받는 것은 서버가 "미안해. 알아요 당신이 누구인가 당신이 누구인지 믿습니다. 그러나 당신은 그냥 가지고 있지 않습니다. 이 리소스에 액세스 할 수있는 권한. 어쩌면 당신이 시스템에 물어 보는 경우 관리자는 훌륭하게, 당신은 허가를 받게됩니다. 그러나 제발 귀찮게하지 마십시오 당신의 곤경이 바뀔 때까지 다시. " 요약하면 누락 된 401 무단 응답을 사용해야합니다. 또는 불량 인증 및 403 개의 금단의 응답을 사용해야합니다. 그 후에, 사용자가 인증되었지만 권한이 부여되지 않은 경우 주어진 자원에서 요청한 작업을 수행하십시오.
HTTP 상태 코드를 사용해야하는 또 다른 멋진 그림 형식.
답변
편집 : RFC2616은 폐기되어 있으며 RFC7231 및 RFC7235를 참조하십시오.
401 무단 :
요청이 이미 인증 자격 증명을 이미 포함 시키면 401 응답은 권한 부여가 해당 자격 증명에 대해 거부되었음을 나타냅니다.
403 금지:
서버는 요청을 이해했지만이를 충족시키는 것을 거부하고 있습니다.
귀하의 유스 케이스에서 사용자가 인증되지 않은 것으로 보입니다.나는 401을 돌려줍니다.
답변
다른 답변이 누락 된 것은 RFC 2616의 맥락에서 인증 및 권한 부여가 RFC 2617의 HTTP 인증 프로토콜에 대해서만 참조한다는 것을 이해해야한다는 것입니다. RFC2617 외부의 구성표 별 인증은 HTTP 상태 코드에서 지원되지 않으며 고려되지 않습니다.401 또는 403을 사용할지 여부를 결정할 때.
간단하고 간략한
무단은 클라이언트가 RFC2617 인증이 아니며 서버가 인증 프로세스를 시작하고 있음을 나타냅니다.금지 된 것은 클라이언트가 RFC2617 인증을 나타내며 권한 부여가 없거나 서버가 요청 된 리소스에 대해 RFC2617을 지원하지 않음을 나타냅니다.
의미는 자신의 롤 - 당신 자신의 로그인 프로세스를 가지고 있고 HTTP 인증을 사용하지 않으면 403은 항상 적절한 응답이고 401을 사용하지 않아야합니다.
상세하고 심층적 인 것
RFC2616에서
10.4.2 401 Unauthorized. 요청에는 사용자 인증이 필요합니다.응답에는 요청 된 자원에 적용 할 수있는 챌린지가 포함 된 WWW 인증 헤더 필드 (14.47 절)가 포함되어야합니다.클라이언트는 요청을 적절한 인증 헤더 필드로 반복 할 수 있습니다 (14.8 절).
그리고
10.4.4 403 금지 서버는 요청을 이해했지만이를 충족시키는 것을 거부합니다.권한 부여는 도움이되지 않으며 요청을 반복해서는 안됩니다.
첫 번째 방법을 염두에 두는 것은이 문서의 컨텍스트에서 "인증"및 "권한 부여"가 RFC 2617의 HTTP 인증 프로토콜을 특별히 나타냅니다.로그인 페이지 등을 사용하면 "로그인"을 사용하여 RFC2617 이외의 방법으로 인증 및 권한 부여를 참조합니다.
따라서 실제 차이는 문제가 문제가 무엇인지 또는 해결책이 있는지 아닙니다.차이점은 서버가 클라이언트가 다음에 수행 할 것으로 기대하는 것입니다.
401은 자원이 제공 될 수 없지만 서버는 클라이언트가 HTTP 인증을 통해 로그인하고 프로세스를 시작하기 위해 응답 헤더를 보내는 것을 요청합니다.아마도 자원에 대한 액세스를 허용 할 수있는 권한이 있지만, 아마도 거기에 있지만, 일어나는 일을 시도하고 보자.
403은 자원을 제공 할 수 없으며 현재 사용자가 RFC2617을 통해이를 해결할 수없고 시도하지 않아도됩니다.이는 인증 수준이 충분하지 않음 (예를 들어, IP 블랙리스트로 인해) 사용자가 이미 인증되었고 권한이 없기 때문에 일 수 있습니다.RFC2617 모델은 사용자가 권한 부여 할 수있는 두 번째 자격 증명 세트가 무시 될 수 있으므로 사용자가 무시할 수 있습니다.어떤 종류의 로그인 페이지 또는 기타 비 RFC2617 인증 프로토콜이 RFC2616 표준 및 정의를 벗어나는 데 도움이되지 않을 수도 있고 도움이되지 않을 수도 있습니다.
편집 : RFC2616은 폐기되어 있으며 RFC7231 및 RFC7235를 참조하십시오.
답변
+-----------------------
| RESOURCE EXISTS ? (if private it is often checked AFTER auth check)
+-----------------------
| |
NO | v YES
v +-----------------------
404 | IS LOGGED-IN ? (authenticated, aka user session)
or +-----------------------
401 | |
403 NO | | YES
3xx v v
401 +-----------------------
(404 no reveal) | CAN ACCESS RESOURCE ? (permission, authorized, ...)
or +-----------------------
redirect | |
to login NO | | YES
| |
v v
403 OK 200, redirect, ...
(or 404: no reveal)
(or 404: resource does not exist if private)
(or 3xx: redirection)
확인은 일반적 으로이 순서로 수행됩니다.
404 리소스가 공개되고 존재하지 않거나 3xx 리디렉션이없는 경우 그렇지 않으면: 401 로그인 또는 세션이 만료되지 않은 경우 403 사용자가 자원에 액세스 할 수있는 권한이없는 경우 (파일, JSON, ...) 404 자원이 존재하지 않거나 아무것도 나타내지 않거나 3xx 리디렉션을 드러내지 않으면
허가되지 않은 상태 : 상태 코드 (401)는 요청에 인증이 필요하다는 것을 나타내는 상태 코드 (일반적으로 사용자가 로그인 할 필요가 있음을 의미합니다 (세션).서버가 알 수없는 사용자 / 에이전트.다른 자격 증명을 반복 할 수 있습니다.참고 : 이것은 'Unauthorized'대신 'Unauthenticated'라는 이름이 지정되어야함에 따라 이것은 혼란 스럽습니다.이는 세션이 만료되면 로그인 후에도 발생할 수 있습니다. 특별한 경우 : 자원의 존재 또는 존재감을 드러내는 것을 방지하기 위해 404 대신에 사용할 수 있습니다 (크레딧 @gingercodeninja)
금지 된 : 상태 코드 (403)가 서버가 요청을 이해했지만이를 충족시키는 것을 거부했다.서버가 알고 있지만 자격 증명이 충분하지 않은 사용자 / 에이전트.자격 증명이 변경되지 않는 한 반복 요청이 작동하지 않습니다. 이는 짧은 시간에 매우 가능하지 않습니다. 특별한 경우 : 자원의 존재가 민감한 데이터를 드러내거나 공격자가 유용한 정보를 제공하는 경우 404 대신 404 대신에 사용될 수 있습니다.
찾을 수 없습니다 : 상태 코드 (404)가 요청 된 자원을 사용할 수 없음을 나타냅니다.User / Agent는 알려지지 만 서버는 자원에 대해 밝히지 않으며 마치 존재하지 않는 것처럼 수행합니다.반복이 작동하지 않습니다.이것은 404의 특별한 사용입니다 (예를 들어 github).
@chrish에 의해 언급했듯이 3xx (301, 302, 303, 307 또는 전혀 리디렉션되지 않고 401을 사용하지 않는) 몇 가지 옵션이 있습니다.
HTTP 리디렉션 코드의 차이점 브라우저가 HTTP 301S를 얼마나 오래 캐시합니까? 로그인 페이지로 리디렉션 할 때 올바른 HTTP 상태 코드는 무엇입니까? 302와 307 리디렉션의 차이점은 무엇입니까?
답변
RFC 2616 (HTTP / 1.1) 403에 따르면 다음과 같은 경우에 전송됩니다.
서버는 요청을 이해했지만이를 충족시키는 것을 거부하고 있습니다.권한 부여는 도움이되지 않으며 요청을 반복해서는 안됩니다.요청 방법이 헤드가 아니고 서버가 요청이 이루어지지 않은 이유를 공개하려는 경우, 실체의 거절 이유를 설명해야합니다.서버 가이 정보를 클라이언트에서 사용할 수있게하지 않으려면 상태 코드 404 (발견되지 않음)를 대신 사용할 수 있습니다.
즉, 클라이언트가 인증을 통해 자원에 액세스 할 수있는 경우 401을 전송해야합니다.
답변
HTTP 인증 (www-authenticate 및 authorization headers)이 사용 중이면 다른 사용자가 요청한 리소스에 대한 액세스 권한을 부여하면 인증을 받으면 401 권한이 없어야합니다.
403은 자원에 대한 액세스가 모든 사람에게 금지되거나 주어진 네트워크로 제한되거나 HTTP 인증과 관련이없는 한 SSL을 통해만 허용되는 경우 리소스에 대한 액세스가 사용되거나 허용되지 않는 경우에 사용됩니다.
HTTP 인증이 사용 중이 아니며 서비스에 쿠키 기반 인증 체계가있는 경우 요즘은 요즘 403 또는 404를 반환해야합니다.
401에 관해서는, 이것은 RFC 7235 (하이퍼 텍스트 전송 프로토콜 (HTTP / 1.1) : 인증)에서 발생합니다.
3.1.401 무단 401 (Unauthorized) 상태 코드는 대상 자원에 대한 유효한 인증 자격 증명이 없기 때문에 요청이 적용되지 않았 음을 나타냅니다.원본 서버는 대상 자원에 적용 가능한 적어도 하나의 챌린지가 포함 된 WWW 인증 헤더 필드 (4.4 절)를 보내야합니다.요청에 인증 자격 증명이 포함 된 경우 401 응답은 권한 부여가 해당 자격 증명에 대해 거부되었음을 나타냅니다.클라이언트는 요청을 새롭거나 대체 된 권한 제 헤더 필드로 반복 할 수 있습니다 (4.1 절).401 응답이 이전 응답과 동일한 챌린지를 포함하고 사용자 에이전트가 적어도 한 번 인증을 이미 시도한 경우 사용자 에이전트는 일반적으로 관련된 진단 정보가 포함되어 있기 때문에 사용자 에이전트가 사용자에게 동봉 된 표현을 제시해야합니다.
403 (및 404)의 의미는 시간이 지남에 따라 변경되었습니다.이것은 1999 년부터 (RFC 2616) :
10.4.4 403 금지 서버는 요청을 이해했지만이를 충족시키는 것을 거부하고 있습니다.권한 부여는 도움이되지 않으며 요청을 반복해서는 안됩니다.요청 방법이 헤드가 아니고 서버가 요청이 이루어지지 않은 이유를 공개하려는 경우, 실체의 거절 이유를 설명해야합니다.서버 가이 정보를 클라이언트에서 사용할 수있게하지 않으려면 상태 코드 404 (발견되지 않음)를 대신 사용할 수 있습니다.
2014 년 RFC 7231 (HTTP / 1.1) : 의미 및 콘텐츠) 403의 의미를 변경했습니다.
6.5.3.403 금지 403 (금지 된) 상태 코드는 서버가 요청을 이해했지만 승인을 거부 함을 나타냅니다.왜 요청이 금지 된 이유를 대중으로 만들고자하는 서버는 응답 페이로드 (있는 경우)의 이유를 설명 할 수 있습니다. 요청에 인증 자격 증명이 제공된 경우 서버는 액세스 권한을 부여하기 위해 불충분 한 것으로 간주합니다.클라이언트는 동일한 자격 증명으로 요청을 자동으로 반복해서는 안됩니다.클라이언트는 새 또는 다른 자격 증명으로 요청을 반복 할 수 있습니다.그러나 자격 증명과 관련이없는 이유로 요청이 금지 될 수 있습니다. 금지 대상 리소스의 현재 존재 여부를 "숨기려는 원본 서버가 대신 404 (발견되지 않음)의 상태 코드로 응답 할 수 있습니다.
따라서 403 (또는 404)은 이제 어떤 것도 의미 할 수 있습니다.새로운 자격 증명을 제공하는 것이 도움이 될 수 있습니다 ... 또는 그렇지 않을 수도 있습니다.
나는 이것이 바뀌었던 이유는 RFC 2616은 오늘날의 웹 앱이 예를 들어 양식과 쿠키와 함께 사용하는 사용자 정의 인증 체계를 빌드 할 때 HTTP 인증이 사용될 때 RFC 2616을 믿습니다.
출처:https://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses
최근댓글