[ https://issues.apache.org/jira/browse/DELTASPIKE-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gerhard Petracek closed DELTASPIKE-1022. ---------------------------------------- > 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)