Filter only works on Query object, not EntityManager.find

mike1106 · **Joined:** Mon Oct 04, 2004 7:13 am **Posts:** 19

I'm using Hibernate JPA, and I thought that Hibernate Filters can be used to logically partition data.

But the filtering only seems to be enforced when I create a query and execute it. The Filtering is NOT enforced when I do an entityManager.find. As this really only delegates to the session.load I don't think my issue is JPA specific.

E.g. Users can only access Addresses to which they are authorised.
I've set up a Filter and enabled it:

Code:

session.enableFilter("tenantFilter").setParameter("tenant", "TENANT1");

and it seems to work fine when executing a search query, i.e. I only see Address in TENANT1 e.g.

Code:

Address instanceT1 = entityManager.createQuery("select A from Address A where key=?").setParameter(1, "12345").getSingleResult()

But if I use the a regular find, I'm able access any Address I want:

Code:

Address instanceT1 = entityManager.find(Address.class, "12345")

The Filter only get applied to Query objects, so it does not really partition the data because I can still access any data I want using entityMnager.find.

So... that makes be think I have to use the @Loader annotation with a @NamedQuery. But the trouble with that is I can't pass parms.

So.. bottom line is, it looks as though I need to make sure my DAOs never use entityManager.find, but instead use a query like the one above.

It all seems odd to me which is why i think i must be doing someting wrong. I would have though that a Filter applied that filtering to ALL Select statements, not just the ones that result from a Query object.

Any advice much appreciated.

cbredesen · **Posted:** Sat Jan 31, 2009 12:22 pm

Filters, by design, apply only to queries, not load/get type operations. The idea is that entity loading operations are done once the ID is already known by the client. A filtered HQL query would never have returned IDs that are not meant to be viewed by a certain client.

danielalexiuc · **Joined:** Thu Mar 05, 2009 11:03 pm **Posts:** 2

I'm not sure if I agree with this decision.

You are implying that the only way a client could possibly know an unauthorized id is if a previous filtered query told them about it. Sounds an awful lot like security through obscurity.

What if they guessed it? Or got the id some other way?

Considering that this kind of filtering is often used for security purposes, is there any other reason that filtering is not applied to load/get type operations?