User doc link for additional criteria
(sent you design doc link previously)
http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Mapping/Additional_Criteria
Cheers,
Guy
On 30/06/2011 10:38 AM, Guy Pelletier wrote:
Hi Laird,
Have a look at @AdditionalCriteria or our @Multitenant solution.
http://wiki.eclipse.org/EclipseLink/Development/AdditionalCriteria
http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Single-Table_Multi-Tenancy.
Cheers,
Guy
On 30/06/2011 10:17 AM, Laird Nelson wrote:
Hello; thanks for a great product and
congratulations on the 2.3 release.
I have a question around security and customization, and am
looking for thoughts on how best to proceed.
In the higher education industry (and I'm sure many others),
access control is paramount. You don't want a work-study
student being able to see the salaries or account balances of
professors, for example.
My question is, what is the best way--or any way, really--to
affect a query such that a subset of what is requested is
actually delivered?
Suppose we have a JPQL query like this:
SELECT p.salary FROM Person p
But the security rules that should be in effect are: "Users in
the 'workstudy' role may only retrieve salary information of
other work-study students". (I am making this silly rule up.)
So when a query is run from our app, we really want it to
translate, as silently as possible, to:
SELECT p.salary FROM Person p WHERE
some
condition that determines whether p is a work-study student
based off p and maybe other information
Loosely speaking, we'd like to inject a WHERE
clause in there where none was there before. Or, in the case
where there was a WHERE clause, we want to add a
condition to it. And in the case of complicated joins, we might
want to add additional conditions in there as well.
Leaving aside the problem of passing parameters for the moment,
is there a single place where such a condition could be
injected? I'll come back to parameters if unparamaterized
constraining is possible.
I should note that I am well aware that I could filter the List
of query results, but I'm looking to push the constraining
information down to the underlying database itself. I'm also
aware that what I'm asking about is more likely than not not
possible.
Thanks,
Laird
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
