[jira] [Commented] (DELTASPIKE-1022) Add support for evaluating access decision voters (defined for @Secured views) after processing view parameters

["Gerhard Petracek (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DELTASPIKE-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15004715#comment-15004715 ] 

Gerhard Petracek commented on DELTASPIKE-1022:
----------------------------------------------

the only approach which works for you would be a lazy check in a face-listener (phase: RENDER_RESPONSE, method #beforePhase).
we have such a check in place as a fallback (esp. if someone replaces the current view-root manually e.g. via UIViewRoot#setViewRoot).
however, there are some special constellations and use-cases which don't allow us to use that as the only approach.

what you can do right now to reach the same is:
{code}
public class PostponeSecurityCheckExtension implements Extension { //+ add it to the extension-config-file
    private final Class accessHandlerClass = ClassUtils.tryToLoadClassForName("org.apache.deltaspike.jsf.impl.security.ViewRootAccessHandler");
    private final PostponeSecurityCheckInterceptor postponeSecurityCheckInterceptorInstance = AnnotationInstanceProvider.of(PostponeSecurityCheckInterceptor.class);

    public void addInterceptor(@Observes ProcessAnnotatedType pat) {
        if (accessHandlerClass != null && pat.getAnnotatedType().getJavaClass().equals(accessHandlerClass)) {
            pat.setAnnotatedType(new AnnotatedTypeBuilder()
                .readFromType(accessHandlerClass).addToClass(postponeSecurityCheckInterceptorInstance).create());
        }
    }
}


@Retention(RUNTIME)
@Target({ TYPE, METHOD })
@InterceptorBinding
public @interface PostponeSecurityCheckInterceptor {
}

@Interceptor
@Priority(100)
@PostponeSecurityCheckInterceptor
public class PostponeSecurityCheckInterceptorImpl implements Serializable {
    public static final String METHOD_NAME = "checkAccessTo";

    @AroundInvoke
    public Object interceptIt(InvocationContext invocationContext) throws Exception {
        if (METHOD_NAME.equals(invocationContext.getMethod().getName()) &&
                !FacesContext.getCurrentInstance().isPostback() &&
                FacesContext.getCurrentInstance().getCurrentPhaseId() != PhaseId.RENDER_RESPONSE) {
            return null;
        }
        return invocationContext.proceed();
    }
}
{code}

that works with the demo you have provided.
however, in this case you need to check, if the access-check in the RENDER_RESPONSE is enough for all your use-cases.

what we can do in the future is to provide a spi for it (with that it would be easier to change the strict approach we use per default).

> Add support for evaluating access decision voters (defined for @Secured views) after processing view parameters
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: DELTASPIKE-1022
>                 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1022
>             Project: DeltaSpike
>          Issue Type: Improvement
>          Components: JSF-Module
>    Affects Versions: 1.5.1
>            Reporter: Juan Pablo Angamarca
>            Priority: Minor
>
> Deltaspike allows for securing views with access decision voters by annotating the view config classes in a typesafe view-config (@Secured). The issue I'm experiencing is, ADVs are evaluated before page parameters are set, and authorization could depend on page parameters, (example: a page that serves to create and edit entities, depending on a entity-id passed to it, or, a particular property of the entity with the passed id).
> The sample application application that demonstrates this can be found at https://github.com/jpangamarca/deltaspike-authorization-demo (there you'll find instructions for running it), and works like this (it is very simplistic, for the sake of demonstration):
> - There are two users, 'john' and 'peter'. john is authorized to create and edit employees, and peter is authorized for edits only (permission codes are 'employee.create' and 'employee.edit', and are stored in a set in User.java). A reference to the currently logged-in user is stored in the UserSession session-scoped bean. The currently logged-in user can be changed at the homepage.
> - The application has a employee.xhtml page. If an employee id is not provided, the page will be used to create a employee. If an id is passed, it will be used to edit an employee.
> - The ADV checks for the id passed to the page to find out what permission the user needs to access the page. But it is evaluated before the id is set (via a page parameter), resulting on 'peter' being unable to edit employees (the id is not set = 'employee.create' is required) and 'john' being authorized with the wrong permission (he has the 'employee.create' permission, but should be authorized with 'employee.edit'). See application logging.
> Seam, for example, evaluates page parameters first, then restrict expressions (analogous to ADVs) and then page actions (see Seam pages.xml: http://shrubbery.homeip.net/c/display/W/Seam+pages.xml#Seampagesxml-restrictrestrict). My Seam application (which I'm porting to CDI) works without any problems with these authorization requirements.
> The application implements a Deltaspike exception handler, which handles the authorization violations.
> Is there any chance to support this kind of authorization requirements?
> Thanks for your attention.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)