Juan Pablo Angamarca created DELTASPIKE-1022:
------------------------------------------------
Summary: 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). 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)
