30
간단한 REST-ish HTTP API를 제공하는 작은 애플리케이션을 작성하고 있습니다. 나는 인증의 결여로 인해 실패 신호를 보내는 방법을 결정하려고 애쓰는 중이다.RESTful API에서 신호 인증 실패
앱에 인증 용 API가 없지만 다른 서비스를 통해 클라이언트가 얻은 세션 토큰을 포함하는 쿠키가 있는지 여부에 따라 다릅니다. 앱은 세션을 확인하고 인증 프로세스를 통해 얻은 신원 정보를 사용하여 앱 별 인증을 수행합니다. 클라이언트가이 앱에 직접 인증 할 방법이 없습니다.
내 문제는 권한이없는 요청을 거부하는 명백한 HTTP 상태 코드 인 "401 Unauthorized"가 "WWW-Authenticate"헤더로 지정된다는 것입니다. rfc2616 sec 10.4.2을 참조하십시오.
응답이 요청 된 자원에 해당하는 시도를 포함하는 WWW 인증 헤더 필드 (제 14.47)를 포함해야한다.
나는 이것이 드문 문제라고 생각하지 않습니다. 보다 일반적인 용도를 포함하도록 단순히 401을 오버로드하는 것이 일반적입니까? 브라우저가 auth/e 대화 상자를 띄우는 것은 어떨까요 (우연히 테스트에서 보지 못했던 것인데, 아마도 POST에서는 발생하지 않을 수도 있습니다).
결론 :이 컨텍스트에서 401을 사용하는 것이 좋습니까? 아니면 더 좋은 해결책이 있습니까? 이 같은
쿠키를 사용하는 경우 RESTful API가 아닙니다. REST 서비스는 정의에 따라 상태 비 저장됩니다. –
공정한 점 - 설명을 RESTful이 아닌 REST-ish로 변경했습니다. 답변은 요청 별 인증을 올바르게 구현하거나 RESTishness에서 내 시도를 포기하는 것이라고 생각하십니까? – j0ni
어려운 점은 응용 프로그램에 따라 다릅니다. REST 접근법에는 몇 가지 장점이 있습니다. 서버 측 세션을 계속 사용하려면 tvanfosson이 말한대로 403을 반환합니다. –