전체 들어오는 요청과 나가는 응답을 ASP.NET WebAPI 프로젝트에 기록하려고합니다. DelegatingHandler에 동의하는 동안, 내 고용주는 HttpModule을 사용해야한다고 주장합니다. 우리에게 왜 그녀에게 설명 할 것이고 DelegatingHandler이고 HttpModule이 아닌 이유는 무엇입니까? 아니면 내가 틀렸어?HttpModule 대 DelegatingHandler - 장점/단점?
나는 DelegatingHandler을 사용할 것입니다. DelegatingHandler은 웹 API 파이프 라인의 일부이며 모든 호스트에서 실행할 수 있습니다. HttpModule은 Web API의 일부가 아니며 IIS가 필요합니다.
HTTP 모듈이 IIS에서 실행되는 웹 API에 대한 옵션 : 직접 질문과 관련된 것은 아니지만
, 나는 두 가지를 포함하여 차이를 강조 다음 MSDN 기사에서 인용거야 . HTTP 모듈을 사용하면 IIS 파이프 라인의 일부로 초기에 보안 코드를 실행할 수 있습니다. HTTP 모듈에서 설정 한 주체는 파이프 라인에서 나중에 실행되는 IIS 구성 요소를 포함하여 모든 구성 요소에 대해 을 사용할 수 있습니다. 예를 들어 AuthenticateRequest 이벤트에 대한 응답으로 HTTP 모듈에서 사용자를 설정하면 사용자 이름이 이고 IIS로그의 주자는 cs-username 필드에 올바르게 기록됩니다. HTTP 모듈의 가장 큰 단점은 세분화 부족입니다. HTTP 모듈은 응용 프로그램에 들어오는 모든 요청에 대해 실행됩니다. 과 같은 다른 기능을 가진 웹 응용 프로그램의 경우 HTTP 인증 모듈 이 한 가지 방법으로 인증을 시행하면 일반적으로 접근 방식만큼 유연하지 않습니다. HTTP 모듈을 사용하는 또 다른 단점은 호스트 -IIS에 대한 종속성입니다. ASP.NET 웹 API에서 제공하는
메시지 처리기 확장 옵션은 보안에 대한 메시지 처리기를 사용의 가장 큰 이점은 그것이, 따라서하지 않는 ASP.NET 웹 API 프레임 워크의 개념이고 기본 호스트 또는 서버 에 의존합니다. 또한 메시지 핸들러는 웹 API 요청에 대해서만 실행됩니다. 메시지 처리기를 사용하는 단점은 미세 제어가 부족한 입니다. 모든 요청 또는 특정 경로에 대해 글로벌 처리기로 실행되도록 메시지 처리기를 구성 할 수 있습니다. 주어진 경로의 경우 여러 컨트롤러를 가질 수 있습니다. 이러한 모든 컨트롤러와 해당 메시지에 포함 된 작업 메서드는 에 해당 경로에 대해 구성된 메시지 처리기에 의해 적용되는 동일한 인증 을 공유해야합니다. 기타 단어의 경우 메시지 처리기 에 의해 구현 된 인증의 최소 세분성이 경로 수준에 있습니다.