웹 페이지가 있지만 사용자에게 충분한 권한이없는 (로그인되지 않았거나 적절한 사용자 그룹에 속하지 않은) 웹 페이지에 적합한 HTTP 응답은 무엇입니까?

401 Unauthorized?
403 Forbidden?
다른 것?

지금까지 내가 읽은 것은 둘 사이의 차이점에 대해서는 명확하지 않습니다. 각 응답에 적합한 사용 사례는 무엇입니까?

Daniel Irvine 의 명확한 설명 :

인증 오류에 대한 HTTP 상태 코드 인 401 Unauthorized에 문제가 있습니다. 바로 그뿐입니다. 인증이 아니라 인증을위한 것입니다. 401 응답을받는 서버는 "인증되지 않았거나 전혀 인증되지 않았거나 잘못 인증 되었으나 다시 인증 한 후 다시 시도하십시오."라고 서버에 알려줍니다. 이를 돕기 위해 항상 인증 방법을 설명하는 WWW-Authenticate 헤더가 포함됩니다 .

이것은 일반적으로 웹 응용 프로그램이 아닌 웹 서버에서 반환되는 응답입니다.

또한 매우 일시적인 것입니다. 서버가 다시 시도하도록 요청하고 있습니다.

따라서 승인을 위해 403 Forbidden 응답을 사용합니다 . 영구적이며 내 응용 프로그램 논리에 연결되어 있으며 401보다 더 구체적인 응답입니다.

서버가 403 응답을 수신하면“죄송합니다. 나는 당신이 누군지 알고 있습니다-당신이 말하는 사람을 믿습니다. 그러나 당신은이 자료에 접근 할 수있는 권한이 없습니다. 시스템 관리자에게 친절하게 문의하면 권한이 부여 될 수 있습니다. 하지만 상황이 바뀔 때까지 다시는 귀찮게하지 마십시오.”

요약하면 401 Unauthorized 응답은 누락되거나 잘못된 인증에 사용되어야하며 403 Forbidden 응답은 사용자가 인증되었지만 주어진 자원에 대해 요청 된 작업을 수행 할 권한이없는 경우에 사용해야합니다.

http 상태 코드 사용 방법에 대한 또 다른 멋진 그림 형식 입니다.

RFC2616 참조 :

401 무단 :

요청에 이미 인증 자격 증명이 포함 된 경우 401 응답은 해당 자격 증명에 대한 인증이 거부되었음을 나타냅니다.

403 금지:

서버가 요청을 이해했지만 요청 이행을 거부하고 있습니다.

최신 정보

유스 케이스에서 사용자가 인증되지 않은 것으로 보입니다. 401을 반환합니다.

편집 : RFC2616 은 더 이상 사용되지 않습니다 ( RFC7231 및 RFC7235 참조) .

RFC 2616의 컨텍스트에서 인증 및 권한 부여는 RFC 2617의 HTTP 인증 프로토콜 만 참조한다는 점을 이해해야합니다. RFC2617 외부의 체계에 의한 인증은 HTTP 상태 코드에서 지원되지 않으며 고려되지 않습니다. 401 또는 403 사용 여부를 결정할 때.

간단하고 간결

Unauthorized는 클라이언트가 RFC2617 인증을받지 않았으며 서버가 인증 프로세스를 시작하고 있음을 나타냅니다. 금지는 클라이언트가 RFC2617 인증을 받았으며 권한이 없거나 서버가 요청 된 자원에 대해 RFC2617을 지원하지 않음을 나타냅니다.

자체 롤업 로그인 프로세스가 있고 HTTP 인증을 사용하지 않는 경우 403은 항상 올바른 응답이며 401은 사용해서는 안됩니다.

상세하고 심층적 인

RFC2616에서

10.4.2 401 무단

요청에는 사용자 인증이 필요합니다. 응답에는 요청 된 자원에 해당하는 챌린지를 포함하는 WWW-Authenticate 헤더 필드 (섹션 14.47)가 포함되어야합니다. 클라이언트는 적절한 Authorization 헤더 필드 (14.8 절)로 요청을 반복 할 수있다.

과

10.4.4 403 금지됨 서버가 요청을 이해했지만 요청 이행을 거부하고 있습니다. 승인은 도움이되지 않으며 요청을 반복해서는 안됩니다.

가장 먼저 명심해야 할 것은이 문서의 맥락에서 "인증"및 "권한 부여"는 RFC 2617의 HTTP 인증 프로토콜을 구체적으로 나타냅니다. 사용자가 만든 롤-온 (roll-your-own) 인증 프로토콜은 언급하지 않습니다. 로그인 페이지 등을 사용합니다. "로그인"을 사용하여 RFC2617 이외의 방법으로 인증 및 권한 부여를 참조합니다.

따라서 실제 차이점은 문제가 아니거나 해결책이 있더라도 아닙니다. 차이점은 서버가 클라이언트가 다음에 할 것을 기대하는 것입니다.

401은 자원을 제공 할 수 없음을 나타내지 만 서버는 클라이언트가 HTTP 인증을 통해 로그인하도록 요청하고 프로세스를 시작하기 위해 응답 헤더를 보냈습니다. 아마도 리소스에 대한 액세스를 허용 할 수있는 권한이있을 수 있지만, 없을 수도 있지만 시도해보고 어떤 일이 일어나는지 보도록합시다.

403은 리소스를 제공 할 수 없으며 현재 사용자에게 RFC2617을 통해이를 해결할 방법이 없으며 시도 할 시점이 없음을 나타냅니다. 인증 수준이 충분하지 않은 것으로 알려져 있지만 (예 : IP 블랙리스트 등) 사용자가 이미 인증되었고 권한이 없기 때문일 수 있습니다. RFC2617 모델은 단일 사용자, 단일 자격 증명이므로 사용자가 권한을 부여 할 수있는 두 번째 자격 증명 집합이있는 경우 무시할 수 있습니다. 그것은 어떤 종류의 로그인 페이지 또는 다른 비 RFC2617 인증 프로토콜이 RFC2616 표준 및 정의를 벗어난 도움이 될 수도 있고 그렇지 않을 수도 있음을 암시하거나 암시하지 않습니다.

편집 : RFC2616 은 더 이상 사용되지 않습니다 ( RFC7231 및 RFC7235 참조) .

  + -----------------------
  | 자원이 있습니까? (비공개 인증 인 경우 종종 확인 후 확인)
  + -----------------------
    | |
 아니요 | v 예
    v + -----------------------
   404 | 로그인되어 있습니까? (인증, 일명 세션 또는 JWT 쿠키가 있음)
   또는 + -----------------------
   401 | |
   403 아니오 | | 예
   3xx vv
              401 + -----------------------
       (404 공개) | 자원을 이용할 수 있습니까? (권한, 승인, ...)
              또는 + -----------------------
             리디렉션 | |
             로그인하려면 NO | | 예
                               | |
                               vv
                               403 OK 200, 리디렉션, ...
                      (또는 404 : 공개하지 않음)
                      (또는 404 : 개인의 경우 리소스가 존재하지 않습니다)
                      (또는 3xx : 리디렉션)

점검은 일반적으로 다음 순서로 수행됩니다.

• 리소스가 공개적이고 존재하지 않거나 xx 리디렉션 인 경우 404
• 그렇지 않으면:
• 로그인하지 않았거나 세션이 만료 된 경우 401
• 403 사용자에게 리소스 액세스 권한이없는 경우 (파일, json 등)
• 404 리소스가 존재하지 않거나 공개하지 않을 경우 3xx 리디렉션

UNAUTHORIZED : 요청에 인증 이 필요함을 나타내는 상태 코드 (401) . 일반적으로 이는 사용자가 로그인 (세션)해야 함을 의미합니다. 서버가 사용자 / 에이전트를 알 수 없습니다. 다른 자격 증명으로 반복 할 수 있습니다. 참고 : '무단'대신 '비인증'으로 이름을 지정 했으므로 혼동됩니다. 세션이 만료 된 경우 로그인 후 발생할 수도 있습니다. 특수 사례 : 자원의 존재 또는 존재 유무를 피하기 위해 404 대신 사용할 수 있습니다 (credits @gingerCodeNinja)

금지 : 서버가 요청을 이해했지만 요청을 이행하지 않았 음을 나타내는 상태 코드 (403). 서버에 알려진 사용자 / 에이전트이지만 자격 증명 이 충분하지 않습니다 . 자격 증명이 변경되지 않는 한 반복 요청은 작동하지 않으므로 짧은 시간 내에는 발생하지 않습니다. 특수 사례 : 자원의 존재 또는 존재 유무를 피하기 위해 404 대신 사용할 수 있습니다 (credits @gingerCodeNinja)

NOT FOUND : 요청 된 자원을 사용할 수 없음을 나타내는 상태 코드 (404). 사용자 / 에이전트는 알려져 있지만 서버는 리소스에 대해 아무 것도 공개하지 않으며 마치 존재하지 않는 것처럼합니다. 반복되지 않습니다. 이것은 404를 특수하게 사용합니다 (예 : github에서 수행).

@ChrisH에서 언급했듯이 리디렉션 3xx (301, 302, 303, 307) 또는 전혀 리디렉션하지 않고 401을 사용하는 몇 가지 옵션이 있습니다 .

• HTTP 리디렉션 코드의 차이점
• 브라우저는 HTTP 301을 얼마나 오래 캐시합니까?
• 로그인 페이지로 리디렉션 할 때 올바른 HTTP 상태 코드는 무엇입니까?
• 302와 307 리디렉션의 차이점은 무엇입니까?

RFC 2616 (HTTP / 1.1) 에 따르면 다음과 같은 경우에 403이 전송됩니다.

서버가 요청을 이해했지만 요청 이행을 거부하고 있습니다. 승인은 도움이되지 않으며 요청을 반복해서는 안됩니다. 요청 방법이 HEAD가 아니고 서버가 요청이 이행되지 않은 이유를 공개하기를 원한다면, 엔티티에서 거절 이유를 설명해야한다. 서버가이 정보를 클라이언트에 제공하지 않으려면 대신 상태 코드 404 (찾을 수 없음)를 사용할 수 있습니다.

즉, 클라이언트가 인증을 통해 리소스에 액세스 할 수 있으면 401을 보내야합니다.

HTTP 인증 ( WWW-Authenticate 및 Authorization 헤더) 이 사용 중이라고 가정 하고 다른 사용자로 인증하여 요청 된 자원에 대한 액세스 권한을 부여하면 401 Unauthorized가 리턴되어야합니다.

403 금지는 리소스에 대한 액세스가 모든 사람에게 금지되거나 지정된 네트워크로 제한되거나 HTTP 인증과 관련이없는 한 SSL을 통해서만 허용 될 때 사용됩니다.

현재 HTTP 인증을 사용하지 않고 쿠키 기반 인증 체계를 표준으로 사용하는 경우 403 또는 404를 반환해야합니다.

401에 대해서는 RFC 7235 (Hypertext Transfer Protocol (HTTP / 1.1) : 인증)에서 제공합니다.

3.1. 401 무단

401 (인증되지 않음) 상태 코드는 요청이 대상 리소스에 대한 유효한 인증 자격 증명이 없기 때문에 적용되지 않았 음을 나타냅니다. 오리진 서버는 대상 자원에 적용 가능한 하나 이상의 챌린지를 포함하는 WWW- 인증 헤더 필드 (섹션 4.4)를 보내야합니다. 요청에 인증 자격 증명이 포함 된 경우 401 응답은 해당 자격 증명에 대한 권한 부여가 거부되었음을 나타냅니다.. 클라이언트는 새로운 또는 교체 된 Authorization 헤더 필드 (4.1 절)로 요청을 반복 할 수있다. 401 응답에 이전 응답과 동일한 시도가 포함되어 있고 사용자 에이전트가 이미 한 번 이상 인증을 시도한 경우 사용자 에이전트는 일반적으로 관련 진단 정보를 포함하므로 동봉 된 표현을 사용자에게 제시해야합니다.

403 (및 404)의 의미는 시간이 지남에 따라 변경되었습니다. 1999 년 (RFC 2616)입니다.

10.4.4 403 금지

서버가 요청을 이해했지만 요청 이행을 거부하고 있습니다.
승인은 도움이되지 않으며 요청을 반복해서는 안됩니다.
요청 방법이 HEAD가 아니고 서버
가 요청이 이행되지 않은 이유 를 공개 하기를 원한다면 , 엔티티에서 거부 이유를 설명해야한다. 서버가이 정보를 클라이언트가 사용할 수 없게하려면 상태 코드 404
(찾을 수 없음)를 대신 사용할 수 있습니다.

2014 년 RFC 7231 (Hypertext Transfer Protocol (HTTP / 1.1) : 의미 및 내용)에서 403의 의미가 변경되었습니다.

6.5.3. 403 금지

403 (금지됨) 상태 코드는 서버가 요청을 이해했지만 승인을 거부 함을 나타냅니다. 요청이 금지 된 이유를 공개하려는 서버는 응답 페이로드에 해당 이유를 설명 할 수 있습니다 (있는 경우).

요청에 인증 자격 증명이 제공된 경우
서버 는 자격 증명이 액세스 권한을 부여하기에 충분하지 않은 것으로 간주합니다. 클라이언트
는 동일한
자격 증명으로 요청을 자동으로 반복해서는 안됩니다 . 클라이언트는 새로운 자격 증명이나 다른 자격 증명으로 요청을 반복 할 수 있습니다. 그러나
신임 정보와 관련이없는 이유로 요청이 금지 될 수 있습니다 .

금지 된 대상 자원 의 현재 존재를 "숨기기"하려는 원 서버는 대신 상태 코드
404 (찾을 수 없음)로 응답 할 수 있습니다.

따라서 403 (또는 404)은 이제 무엇이든 의미 할 수 있습니다. 새로운 자격 증명을 제공하면 도움이 될 수도 있고 그렇지 않을 수도 있습니다.

이것이 변경 된 이유는 오늘날 웹 응용 프로그램이 예를 들어 양식 및 쿠키를 사용하여 사용자 지정 인증 체계를 작성할 때 HTTP 인증이 사용될 것이라고 가정 한 RFC 2616 때문이라고 생각합니다.

이것은 오래된 질문이지만 실제로 제기되지 않은 한 가지 옵션은 404를 반환하는 것이 었습니다. 보안 측면에서 가장 높은 투표 응답은 잠재적 인 정보 유출 취약점으로 인해 어려움을 겪습니다 . 예를 들어, 해당 보안 웹 페이지는 시스템 관리 페이지이거나 더 일반적으로 사용자가 액세스 할 수없는 시스템의 레코드라고 가정하십시오. 이상적으로 악의적 인 사용자가 페이지 / 레코드가 있다는 것을 알기를 원하지 않을 것입니다. 이와 같은 것을 만들 때 내부 로그에 인증되지 않은 / 승인되지 않은 요청을 기록하려고하지만 404를 반환합니다.

OWASP에는 공격자가 이러한 유형의 정보를 공격의 일부로 사용하는 방법에 대한 추가 정보 가 있습니다.

• 401 Unauthorized : 당신이 누군지 모르겠습니다. 인증 오류입니다.
• 403 금지 : 본인이 누구인지 알고 있지만이 리소스에 액세스 할 수있는 권한이 없습니다. 인증 오류입니다.

이 질문은 얼마 전에 요청되었지만 사람들의 생각은 계속 진행됩니다.

이 초안의 섹션 6.5.3 (Fielding and Reschke에 의해 작성)은 RFC 2616에 문서화 된 것과 약간 다른 의미의 상태 코드 403을 제공합니다 .

많은 인기있는 웹 서버 및 프레임 워크에서 사용하는 인증 및 권한 부여 체계에서 발생하는 상황을 반영합니다.

가장 중요하다고 생각하는 부분을 강조했습니다.

6.5.3. 403 금지

403 (금지됨) 상태 코드는 서버가 요청을 이해했지만 승인을 거부 함을 나타냅니다. 요청이 금지 된 이유를 공개하려는 서버는 응답 페이로드에 해당 이유를 설명 할 수 있습니다 (있는 경우).

요청에 인증 자격 증명이 제공된 경우 서버는 액세스 자격 증명이 충분하지 않은 것으로 간주합니다. 클라이언트는 동일한 자격 증명으로 요청을 반복해서는 안됩니다. 클라이언트는 새로운 자격 증명이나 다른 자격 증명으로 요청을 반복 할 수 있습니다. 그러나 신임 정보와 관련이없는 이유로 요청이 금지 될 수 있습니다.

금지 된 대상 자원의 현재 존재를 "숨기기"하려는 원 서버는 대신 상태 코드 404 (찾을 수 없음)로 응답 할 수 있습니다.

어떤 규칙을 사용하든 중요한 것은 사이트 / API 전체에 균일 성을 제공하는 것입니다.

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)

의미 : 인증 과 무관

... 승인이 도움이되지 않습니다 ...

자세한 내용은:

• 서버가 요청을 이해했지만 요청 이행을 거부하고 있습니다.

• 실체의 거절 사유를 설명해야한다

• 상태 코드 404 (찾을 수 없음)를 대신 사용할 수 있습니다.

  (서버가이 정보를 클라이언트로부터 유지하려는 경우)

로그인하지 않았거나 적절한 사용자 그룹에 속하지 않습니다

두 가지 경우를 언급했습니다. 각 사례마다 다른 응답이 있어야합니다.

1. 전혀 로그인하지 않은 경우 401 Unauthorized를 반환해야합니다.
2. 로그인했지만 적절한 사용자 그룹에 속하지 않으면 403 Forbidden을 반환해야합니다.

이 답변에 대한 의견을 바탕으로 RFC에 메모하십시오.

사용자가 로그인하지 않은 경우 인증되지 않은 HTTP에 해당하는 HTTP는 401이며 RFC에서 인증되지 않은 것으로 잘못 간주됩니다. 로 섹션 10.4.2 에 대한 상태 401 권한 :

"요청에는 사용자 인증이 필요 합니다 ."

인증되지 않은 경우 401이 올바른 응답입니다. 그러나 승인되지 않은 경우 의미 적으로 올바른 의미에서 403이 올바른 응답입니다.

이것은 의미입니다 :

401 : 사용자가 (올바로) 인증되지 않았으며 자원 / 페이지에 인증이 필요함

403 : 사용자가 인증했지만 그의 역할 또는 권한이 요청 된 리소스에 액세스 할 수 없습니다.

이것은 내 머리보다 여기 어느 곳보다 간단합니다.

401 : 이것을 보려면 HTTP 기본 인증이 필요합니다.

403 :이 내용을 볼 수 없으며 HTTP 기본 인증이 도움이되지 않습니다.

사용자가 사이트의 표준 HTML 로그인 양식을 사용하여 로그인해야하는 경우 401은 HTTP 기본 인증에만 해당되므로 적합하지 않습니다.

/includes웹과 관련하여 해당 리소스가 전혀 존재하지 않으므로 404와 같이 403을 사용하여에 대한 액세스를 거부하지 않는 것이 좋습니다 .

403은 "로그인해야합니다"로 남습니다.

즉, 403은 "이 자원에는 HTTP 기본 인증 이외의 인증 형식이 필요합니다"를 의미합니다.

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

브라우저에서 401은 사용자가 새 자격 증명을 입력 할 수있는 인증 대화 상자를 시작하지만 403은 그렇지 않다는 점을 고려해야합니다. 브라우저는 401이 반환되면 사용자는 다시 인증해야한다고 생각합니다. 따라서 401은 유효하지 않은 인증을 나타내고 403은 권한이 없음을 나타냅니다.

다음은 중요한 문구를 굵게 표시하여 인증 또는 권한 부여에서 오류가 반환되는 논리의 일부 사례입니다.

• 자원에는 인증이 필요하지만 자격 증명 이 지정 되지 않았습니다 .

401 : 클라이언트가 자격 증명을 지정해야합니다.

• 지정된 자격 증명이 잘못된 형식 입니다.

400 : 구문 오류가 항상 400을 반환해야하므로 401도 403도 아닙니다.

• 지정된 자격 증명 이 존재하지 않는 사용자 를 참조 합니다 .

401 : 클라이언트가 유효한 자격 증명을 지정해야합니다.

• 지정된 자격 증명 이 유효하지 않지만 유효한 사용자를 지정하십시오 (또는 지정된 사용자가 필요하지 않은 경우 사용자를 지정하지 마십시오).

401 : 클라이언트는 유효한 자격 증명을 지정해야합니다.

• 지정된 자격 증명 이 만료되었습니다 .

401 : 이것은 일반적으로 유효하지 않은 자격 증명을 갖는 것과 동일하므로 클라이언트가 유효한 자격 증명을 지정해야합니다.

• 지정된 신임 정보는 완전히 유효하지만 특정 자원으로 충분 하지는 않지만 더 많은 권한이있는 신임 정보는 가능합니다.

403 : 유효한 자격 증명을 지정하면 현재 자격 증명이 이미 유효하지만 권한이 없기 때문에 리소스에 대한 액세스 권한이 부여되지 않습니다.

• 자격 증명에 관계없이 특정 리소스 에 액세스 할 수 없습니다 .

403 : 자격 증명에 관계없이 유효하므로 자격 증명을 지정해도 도움이되지 않습니다.

• 지정된 자격 증명은 완전히 유효하지만 특정 클라이언트가 되는 차단 을 사용하는.

403 : 클라이언트가 차단 된 경우 새 자격 증명을 지정해도 아무 작업도 수행되지 않습니다.

영어로:

401

귀하는 잠재적으로 액세스가 허용되지만이 요청으로 인해 어떤 이유로 거부되었습니다. 잘못된 비밀번호와 같은? 올바른 요청으로 다시 시도하면 성공 응답이 표시됩니다.

403

당신은 결코 허용되지 않습니다. 당신의 이름은 목록에 없습니다, 당신은 절대 들어 가지 않을 것입니다, 다시 시도 요청을 보내지 마십시오, 그것은 항상 거부됩니다. 저리가

문제에 대한 최신 RFC ( 7231 및 7235 )를 고려할 때 유스 케이스는 매우 분명한 것으로 보입니다 (이탈리아어 추가).

• 401은 인증되지 않은 것입니다 ( "유효하지 않은 인증"). 즉 '나는 당신이 누군지 모릅니다. 또는 당신이 당신이 누구인지 당신을 믿지 않습니다.'

401 무단

401 (인증되지 않음) 상태 코드는 요청이 대상 리소스에 대한 유효한 인증 자격 증명 이 없기 때문에 적용되지 않았 음을 나타냅니다 . 401 응답을 생성하는 서버는 대상 자원에 적용 가능한 하나 이상의 시도를 포함하는 WWW- 인증 헤더 필드 (섹션 4.1)를 보내야합니다.

요청에 인증 자격 증명이 포함 된 경우 401 응답은 해당 자격 증명에 대한 권한 부여가 거부되었음을 나타냅니다. 사용자 에이전트는 새로운 또는 교체 된 Authorization 헤더 필드 (4.2 절)로 요청을 반복 할 수있다. 401 응답에 이전 응답과 동일한 시도가 포함되어 있고 사용자 에이전트가 이미 한 번 이상 인증을 시도한 경우 사용자 에이전트는 일반적으로 관련 진단 정보를 포함하므로 동봉 된 표현을 사용자에게 제시해야합니다.

• 403은 승인되지 않은 것 ( "승인 거부")입니다. 즉, '내가 누구인지 알고 있지만이 리소스에 액세스 할 수있는 권한이 없습니다.'

403 금지

403 (금지됨) 상태 코드는 서버가 요청을 이해했지만 승인을 거부 함을 나타냅니다 . 요청이 금지 된 이유를 공개하려는 서버는 응답 페이로드에 해당 이유를 설명 할 수 있습니다 (있는 경우).

요청에 인증 자격 증명이 제공된 경우 서버는 자격 증명이 액세스 권한을 부여하기에 충분하지 않은 것으로 간주합니다. 클라이언트는 동일한 자격 증명으로 요청을 자동으로 반복해서는 안됩니다. 클라이언트는 새로운 자격 증명이나 다른 자격 증명으로 요청을 반복 할 수 있습니다. 그러나 신임 정보와 관련이없는 이유로 요청이 금지 될 수 있습니다.

금지 된 대상 자원의 현재 존재를 "숨기기"하려는 원 서버는 상태 코드 404 (찾을 수 없음)로 응답 할 수 있습니다.

401 vs 403의 경우 여러 번 답변되었습니다. 이것은 본질적으로 '애플리케이션'토론이 아닌 'HTTP 요청 환경'토론입니다.

롤-인-로그인 문제 (응용 프로그램)에 대한 질문이있는 것 같습니다.

이 경우 HTTP Auth와 로그인 페이지 (HTTP Auth 설정에 묶이지 않음)를 사용하지 않는 한 단순히 로그인하지 않으면 401 또는 403을 보내기에 충분하지 않습니다. 파일에 대한 애플리케이션 레벨 액세스를 위해 요청 된 자원 대신 롤-인-로그인 화면이있는 "201 Created"를 찾고있는 것 같습니다. 이것은 말합니다 :

"내가 들었다. 여기 있지만, 대신 시도해 보자 (볼 수 없다)"