[
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)
