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: ErrorViewAwareAccessDeniedException 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 <rainer.schoen....@gmail.com>
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
