PhaseListener를 사용하고 있습니다. 그리고 RESTORE_VIEW에서 내 자격 증명을 직접 INVOKE_APPLICATION 및 RENDER_RESPONSE까지 사용할 수 있습니다. 어느 것이 합리적인지. 이러한 자격 증명의 유효성을 검사 할 때 가장 좋은 방법이 무엇인지 궁금합니다.어느 단계에서 JSF의 로그인 시도를 차단해야합니까?
나는 RESTORE_VIEW에서 유효성을 검사 할 수 있다고 생각하고 있습니다. 나는 그것이 보안 위험일지도 모른다고 생각하기 때문에 UPDATE_MODEL까지 기다리고 싶지 않다. 조금 더 불확실하지만 APPLY_REQUEST 및 PROCESS_VALIDATIONS을 통해 단계를 실행해야하는 경우 ...
아이디어가 있으십니까?
실제로는 RESTORE_VIEW 단계가 JSF 자원에 대한 액세스 제어를 시행하는 이상적인 장소입니다. 페이지의 요청주기의 첫 번째 단계입니다. 요청이 승인되지 않은 경우 그 이상으로 요청을 진행할 이유가 없습니다.
액세스 제어와 같은 기본 서비스를위한 위상 및 위상 왜곡기에 대해 소란스럽게 다루지 않아도된다는 사실 외에도 (이 답변 당시) PhaseListener 주입 대상이 아닙니다. 즉, @EJB, @Inject 및 @ManagedProperty은 phaselistener에서 작동하지 않습니다. 당신이 그것을하지 않는 한 @ManagedBean. 즉, 인증 확인을 수행하는 데 필요할 수있는 서비스는 phaselistener에서 사용할 수 없습니다.
"Best Practice"에 대한 권한이 아니지만 제 모범 사례에 대한 아이디어는 문제를 해결하기위한 깨끗하고 유지 보수 가능하며 재사용 가능한 접근 방식입니다. IMO, 페이지에 대한 액세스 제어의 두 깨끗하고 최소 침습적 방법은
서블릿 필터 있습니다 :이 웹 리소스 액세스 제어의 테스트 진정한 방법이며 JSF-독립적이다. 단계 나 어떤 종류의 J2EE에 대해서도 걱정할 필요가 없습니다. This은 JSF 자원을 보호하는 서블릿 필터의 아주 간단한 예입니다.
JSF 페이지 레벨 인증 : JSF preRenderView 이벤트를 사용하여 JSF 페이지에 대한 액세스를 확인할 수 있습니다.이것은 본질적으로 RESTORE_VIEW 단계에서 개막과 자원의 무리의 사용과 관련하여 여기에 있습니다 :
동의. 나는 두 가지 접근법을 모두 사용했으며 필요한 경우 로그인 할 때 모달 창을 팝업하는 접근 번호 2를 사용하고자합니다. – Catfish
요청이 정상적인 수명주기를 통과해야하는 것이 가장 이상적입니다.이 기능을 사용하면 max에서 스테이지를 원래 용도로 활용하는 이점을 얻을 수 있습니다. 특정 필드에 대한 유효성 검사기를 도입하려고하지만 요청이 처리되기 전에 이전 코드 자체에서 유효성 검사기의 논리를 이동하는 것이 유일한 옵션이므로 성가신 작업이 될 것입니다.
제 제안은 요청이 원래 라이프 사이클을 거치게 할 것입니다.
그리고 성명 "보안 상 위험 할 수 있으므로 UPDATE_MODEL까지 기다리고 싶지 않습니다."이 인용문에 대한 몇 가지 사실을 요구한다면 대안 솔루션에 대해 논의 할 수 있습니다.
내가 의미하는 바는 폼 로그인을 가로 채길 원했기 때문에 UPDATE_MODEL 이전에해야 할 일을해야하고, 그 후에는 일을 끝내면 위험으로 보일 수있다. . –
_i는 내 자격 증명을 RESTORE_VIEW_에서 직접 볼 수 있습니다. 처음으로 로그인 페이지를 쳤을 때와 구성 요소 트리를 처음 만들 때 자격 증명을 사용할 수 있습니까? –
글쎄, 로그인 페이지에 충돌, 자격 증명은 null입니다. 로그인 제출을 누르면 자격 증명이로드 된 다음 RESTORE_VIEW에서 표시됩니다. –
JSF 위상 수신기를 전혀 사용하지 마십시오! – BalusC