hi rainer, it's needed because some component libraries work slightly different (e.g. in case of inline-dialog,... handling). thx for the info! we already saw that the result is different (depending on the jsf-impl). that's what we check currently.
regards, gerhard 2013/4/10 Rainer Schön <[email protected]> > Hello Gerhard > > Again, thanks for the quick answer. > > Your solution with the result cache only solves the problem of multiple > execution of the security check routine. But it does not solve the firing > of the security exception thrown twice, if the test is negative. > > The flow of a security check for a single protected @View is executed as > follows according to my debugger: > > Security test passes: > > 1st invocation: SecurityAwareViewHandler.**createView(FacesContext, > String) line: 92 > result: success > > 2nd invocation: DeltaSpikePhaseListener.**checkSecuredView(FacesContext) > line: 116 > [onAfterRestoreView event] > > 3d invocation: DeltaSpikePhaseListener.**checkSecuredView(FacesContext) > line: 116 > [onBeforRenderResponse event] > > I agree, if the security test outcome is cached, there is not much side > effect with this. > > > Security test fails: > > 1st invocation: as above, result: failed > > 2nd invocation: as above > > Side effects: ErrorViewAwareAccessDeniedExce**ption fired twice for the > same check. > > Is this multiple security check intentionally? What is the reason for it? > > Regards > Rainer > > > > > > > Am 10.04.2013 11:39, schrieb Gerhard Petracek: > > hi rainer, >> >> yesterday i committed an improved request-scoped cache. >> however, if it's enough to do your check only once (e.g. per >> session/workflow/...), you can use a custom cache in your >> AccessDecisionVoter. >> (an AccessDecisionVoter is a std. cdi bean -> you can use any cdi scope >> for >> it). >> >> regards, >> gerhard >> >> >> >> 2013/4/10 Rainer Schön <[email protected]> >> >> Hi all >>> >>> Now my last observation regarding the security module: When @Secured is >>> applied to a ViewConfig the DecisionVoter is called: >>> >>> a) 3 times, when the security check passes and >>> b) 2 times, when the security check fails >>> >>> This is not the behavior I expect and can lead to problems, when the >>> check >>> is expensive and/or in case of b) where security exceptions are thrown >>> twice and thus must be filtered out in the exception handler in some way >>> if >>> the action taken should be unique. >>> >>> If @Secured is applied to a bean or method, everything works fine. >>> >>> Regards >>> Rainer >>> >>> >> >
