You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@deltaspike.apache.org by Rainer Schön <ra...@gmail.com> on 2013/04/10 11:19:58 UTC

DecisionVoter called multiple times when @Secured is applied to a ViewConfig

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

Re: DecisionVoter called multiple times when @Secured is applied to a ViewConfig

Posted by Gerhard Petracek <ge...@gmail.com>.

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 <ra...@gmail.com>

> 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 <ra...@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
>>>
>>>
>>
>

Re: DecisionVoter called multiple times when @Secured is applied to a ViewConfig

Posted by Rainer Schön <ra...@gmail.com>.

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 <ra...@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
>>
>

Re: DecisionVoter called multiple times when @Secured is applied to a ViewConfig

Posted by Gerhard Petracek <ge...@gmail.com>.

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 <ra...@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
>