html 기반 로그인 양식으로 http 401 상태 코드를 반환해야합니까?

html 기반 로그인 양식으로 http 401 상태 코드를 반환해야합니까? 이 페이지는 전용 로그인 양식이며 다른 의미있는 콘텐츠는 없으며 사이트 프레임 워크입니다. 그러나 URL은 의미있는 내용은 있지만 로그인이 필요한 페이지에 대한 것일 수 있습니다. 이 설정은 상태 코드 401 만 반환하며 기본 인증을 요구하는 메시지는 표시하지 않습니다.

표준을 보면 401은 html 기반 로그인 양식에 부적절한 상태 코드 인 것 같습니다. 그러나 나는 그렇게함으로써 어떤 나쁜 결과를 경험하거나들은 적이 없다.

401을 보낼 때, "응답에는 요청 된 자원에 해당하는 챌린지를 포함하는 WWW- 인증 헤더 필드 (섹션 14.47)가 포함되어야합니다."

여기에 언급 된 요구 사항 :

http://tools.ietf.org/html/rfc2616#section-10.4.2

여기에 자세히 설명되어 있습니다.

http://tools.ietf.org/html/rfc2617#section-3.2.1

검색 엔진을 사용하여 로그인 양식의 존재 여부에 따라 페이지를 색인 생성하도록 설득 할 수있는 방법이 있지만 http 상태 코드, 특히 401을 사용하는 것이 좋습니다. WWW-Authenticate 헤더 요구 사항이 아닌 경우 완벽하게 일치합니다.

이 경우 401을 사용하지 않아야하는 이유가 있습니까? 의미 적으로 http 수준에서 권한 부여되지 않는 것과 응용 프로그램 수준에서 권한 부여되는 것 사이에는 어떤 차이가 있습니까? 분명히 둘 다 가질 수 있지만 응용 프로그램 수준에서 쉽게 구현하지 않기 위해 http 수준에서 인증하지 않습니까?

참고로 RFC 2616 에서는 401 응답에 RFC 2617 WWW-Authenticate 헤더 가 수반되어야합니다 . 다음과 같은 가짜 헤더를 보내 기술적으로 해당 요구 사항을 준수 할 수 있다고 생각합니다.

WWW-Authenticate: Bogus realm="blahblah", comment="use form to log in"

그러나 나는 그들이 이해하는 도전이없는 401 응답이 제시되면 브라우저가 무엇을 할 것인지 전혀 모른다. 나는 것이다 가정 (RFC 2616 인증이 실패 할 경우 그들이해야한다고 말했습니다로), 그러나 어느 쪽도 RFC 그렇게 명시 적으로 말할 것 같다 그들이 합법적으로 단지 일반 오류 메시지가 표시 될 수 있도록, 사용자에게 요청 본문을 제시 할 모든 이들의 경우 대부분을 대신에.

가능한 대안은 (다른 사람들처럼 200 응답 만 사용하지 않으려는 경우) 403 금지 상태 코드 를 사용하는 것 입니다. 이것은 널리 사용되는 응답 코드이며, 아는 한 거의 모든 대화 형 사용자 에이전트 (예 : 검색 엔진 또는 다운로드 관리자와 달리 브라우저)는 최소한 사용자에게 콘텐츠를 제공하여 이에 대응해야합니다. 충분히 길면 .

403 상태 코드에 대한 설명에서 "[화]가 도움이되지 않을 것"이라고 말하고 있지만, 이는 RFC 2617 인증 또는 유사한 프로토콜 수준 권한 부여 메커니즘을 참조하여 IMO를 이해해야합니다. 브라우저에 관한 한, 양식을 제출하고 응답으로 쿠키를 수신하는 것이 "권한 부여"또는 다른 것으로 계산되는지 여부는 알 수 없습니다.

일반적으로 사용되는 메커니즘 중 하나 는 별도의 로그인 페이지 로 임시 리디렉션 하여 인증되지 않은 요청에 응답하는 것 입니다. 원래 URL은 매개 변수로 전달되어 사용자가 성공적인 인증 후에 다시 리디렉션 될 수 있습니다. 그러나 순진한 구현을 통해 악의적 인 사용자가 로그인 후 사용자를 임의의 URL로 리디렉션하는 로그인 링크를 만들 수 있습니다. 이것이 보안 문제 일 수있는 경우이를 방지하기위한 단계 (예 : 수락 만)를 수행해야합니다. 알려진 안전한 패턴과 일치하는 반환 URL 또는 수정을 방지하기 위해 반환 URL을 메시지 인증 코드 로 보호합니다 .

어쨌든 로그인 후 HTTP 쿠키를 사용하여 인증 토큰을 저장 하는 경우 부적절한 캐싱을 방지하기 위해 (인증 전후에) Vary 헤더를 응답에 포함시켜야합니다 Vary: Cookie.

먼저 페이지에 로그인이 필요한 경우 robots.txt로 차단해야합니다.

둘째, 로봇이 페이지에 도달하면 401 오류가 적절합니다.

아마도 상태 코드는 사람이 아닌 사람과 일부 브라우저에 유용 할 수 있습니다. ]

로그인 방법으로 독립적으로 올바른 헤더를 보내야합니다

예를 들어 나중에 HTML 코드의 전체가 아닌 페이지 헤더를 요청하여 자체적으로 인증하는 래퍼 클라이언트 (웹 브라우저 아님)를 작성해야 할 수도 있습니다.

사용자 목록과 동일한 데이터베이스를 사용하여 두 가지 방법으로 로그인 응용 프로그램을 구현할 수 있습니다