브라우저가 루트 url에 깊은 URL에 설정된`Authorization` 헤더를 보내지 않았습니다.

Question

일부 URL에서 HTTP Basic Auth를 요청하면 브라우저는이 URL과 다른 URL에 대해서만 Authorization 헤더를 보냅니다. PHP로 작성된

테스트 케이스 스크립트 : 자격 증명을 요구하는 세 가지 URL이 있습니다 http://testauth.veadev.tk/

(당신은 어떤 임의 사용할 수 있습니다) . 로그 아웃 링크 (Internet Explorer에서 작동하지 않는 브라우저 인증 양식에서 "취소"버튼을 누른 후 현재 자격 증명을 삭제합니다). 루트 URL 및 일부 더 깊은 URL 테스트에 연결됩니다.

질문 : HTTP/1.0 401 Unauthorized이 /system/dev에서 전송 된 경우

1. 왜 / URL에서 Authorization 헤더를 전송하지 브라우저? 반복하려면 : http://testauth.veadev.tk/을 열고 Auth2을 클릭하고 자격 증명을 입력하면 그 후에 /으로 전달됩니다. Auth: null은 브라우저에서 인증서 헤더를 보내지 않았 음을 의미합니다. HTTP/1.0 401 Unauthorized이 /dev에서 전송 된 경우

2. 왜 브라우저 /에서 Authorization 헤더를 보낼 수 있습니까? 반복하려면 http://testauth.veadev.tk/을 열고 Auth1을 클릭하고 자격 증명을 입력하면 그 후 /으로 전달됩니다. Auth: string 'Basic dHQ6dHQ=' (length=14)과 같은 것을 볼 수 있는데 이는 브라우저에서 자격 정보 헤더를 보냈다는 의미입니다.

3. 당신은 첫 번째 경우를 반복 한 다음 Root에서 자격 증명 및 기타 모든 페이지를해야합니다 Auth1을 클릭합니다. 왜?

4. 당신은 Auth3 (/some/deep/and/long/url)를 클릭하면 다른 곳 Page3 (/some/deep/and/long/3)과에서 자격 증명을해야합니다. 왜?

는 시험 사이에 자격 증명 상태를 지 웁니다 브라우저를 다시 시작하거나 (파이어 폭스, 구글 크롬)을 다시 돌아 인증 형태 Logout, Cancel 및 Root을 클릭합니다.

Authorization 헤더를 보내는 규칙은 무엇입니까?

Answer 1

RFC 2617, 섹션 2 주 :

클라이언트는 요청-URI의 경로 필드에 마지막 상징적 요소의 깊이보다 또는 깊은 모든 경로는 가 보호 내에 있다는 것을 가정해야 현재 기본 렐름 값 에 의해 지정된 공간. 클라이언트는 에 해당하는 인증 헤더를 서버로부터 다른 챌린지를받지 않고 공간에있는 리소스에 대한 요청으로 선제 적으로 보낼 수 있습니다 (MAY).

다이제스트 챌린지 3을 사용하는 경우.2는 WWW-Authenticate 헤더에 domain을 지정하여 보호 공간을 나타낼 수 있음을 나타냅니다. 그걸 domain=/과 같은 것으로 설정하려고합니다. 이것이 기본 인증과 함께 작동하는지 확신 할 수는 없지만 시도해도 좋을 것입니다. 그렇지 않은 경우 다이제스트 권한 부여는 작업하기가 훨씬 어렵지 않고 조금 더 안전합니다.