[hibernate-dev] Why don't session filters affect UPDATE / DELETE statements?
I am curious as to why the decision was made to not append a WHERE clause to deletes and updates that could be affected by a session filter. I was looking at the source for HqlSqlWalker.postProcessDML, and it has the comment "append any filter fragments; the EMPTY_MAP is used under the assumption that currently enabled filters should not affect this process." So, it seems this was a conscious choice. I would actually like filters to affect updates and deletes and will probably modify this class to enable this. My reasoning is that if you have a filter turned on and perform a select then perform an update using HQL you would expect it to only modify those things returned in the select (lets ignore the fact that this is a race condition as I am oversimplifying). We are using session filters to automatically restrict a logged in user's view of certain data. This works great for selects, but obviously allows HQL updates and deletes to bypass this restricted view. So, my questions are, why this choice? and would you consider changing your mind? Thanks, Jason ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate Filters and EntityManager.find
Hi everyone. I know that Hibernate session filters do not apply to find/load operations because the assumption was made that if you know the ID of the entity you wish to load, why tack on the extra WHERE condition. Please let me explain my use case for filters and illustrate why this assumption is incorrect. We use filters to do data separation. For example, separating one customers data from another's. We also have other filters that do finer grained object visibility conditions. But lets take a look at customer data separation since its the easiest to understand. The advantage of doing customer data separation in this way is that developers don't need to think about it. It just works, and it works *automatically*. The problem comes in when you want to do something like em.find(User.class, 1). No WHERE clause is attached to the SQL statement. Yes, I know the ID, but I really want to tack on to the WHERE clause "AND customerId = 3" to make sure that someone isn't fuzzing the ID parameter to try and get at another customer's data. The workaround we have is another mechanism that validates the entity in a PostLoad entity listener and throws an exception if the customerId != the request's customerId. This is "ok" for the simple example I laid out here. However, we now have many more filters that implement complex visibility rules based on subselects and oracle CONNECT BY clauses which cannot be implemented using a simple equality check in java. The best, most performant, solution is to be able to apply the filter clause to the EntityManager.find operation. What is your take on this? Thanks, Jason Clawson ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Filters and EntityManager.find
Thanks for your response. Yes it is multi-tenency however that's just 1 filter of the 8 we have. We use it for more than just that. For example, within a single customer, there are object visibility permissions based on a complex interaction between roles and a tree with inheritance. Whether or not a user can see a particular object is determined by a recursive tree traversing oracle CONNECT BY clause. These different visibility filters we have are only applied to specific entities. Filters are the right mechanism to handle this as they contain all the necessary semantics We can disable them for certain requests if the current user is an admin, or we can even do it for a few specific queries with our sudo concept. They can be applied to specific entities and multiple filters can be applied to the same entity. And since a relatively recent release they affect DML operations (I had to patch hibernate to do this a while ago). The multitenency in 4.0 won't work for us. We have a single schema based multi tenency. The discrimination based one probably won't work either because we need to be able to write a custom SQL clause like we can in filters. It would work for customer data separation probably, but our other 7 filters can not be modeled in that way since they rely on some complex SQL clauses. I understand filters work as intended. Can you explain a little about why it was intended to ignore the active filters when doing a find? And why respecting the filters on a find is bad? Thanks, Jason Clawson Sent from my iPhone On Nov 30, 2011, at 7:30 AM, Steve Ebersole wrote: > What you are doing is called multi-tenancy. > > Hibernate 4 has more explicit support for multi-tenant data. Unfortunately > 4.0 only supports cases where the schema is replicated on multiple > databases/schemas. There will also be support for discrimination-based > multi-tenancy at some point in 4.x (4.1 or 4.2). If you want to help develop > that feature, that would be great. > > However, I am not going to change the way/places that filters are applied. > They work exactly as intended. > > > On Tue 29 Nov 2011 11:24:19 AM CST, Jason Clawson wrote: >> Hi everyone. I know that Hibernate session filters do not apply to >> find/load operations because the assumption was made that if you know the >> ID of the entity you wish to load, why tack on the extra WHERE condition. >> Please let me explain my use case for filters and illustrate why this >> assumption is incorrect. >> >> We use filters to do data separation. For example, separating one >> customers data from another's. We also have other filters that do finer >> grained object visibility conditions. But lets take a look at customer >> data separation since its the easiest to understand. The advantage of >> doing customer data separation in this way is that developers don't need to >> think about it. It just works, and it works *automatically*. The problem >> comes in when you want to do something like em.find(User.class, 1). No >> WHERE clause is attached to the SQL statement. Yes, I know the ID, but I >> really want to tack on to the WHERE clause "AND customerId = 3" to make >> sure that someone isn't fuzzing the ID parameter to try and get at another >> customer's data. >> >> The workaround we have is another mechanism that validates the entity in a >> PostLoad entity listener and throws an exception if the customerId != the >> request's customerId. This is "ok" for the simple example I laid out here. >> However, we now have many more filters that implement complex visibility >> rules based on subselects and oracle CONNECT BY clauses which cannot be >> implemented using a simple equality check in java. The best, most >> performant, solution is to be able to apply the filter clause to the >> EntityManager.find operation. >> >> What is your take on this? >> >> Thanks, >> >> Jason Clawson >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > -- > st...@hibernate.org > http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Filters and EntityManager.find
I found the bug for the multitenency you described in 4.x: https://hibernate.onjira.com/browse/HHH-6054. There is a comment on there from Damien Hollis which describes one of the scenarios we face and have solved with filters + persistence listeners. (I would like to note that our solution is automatic based on an object type inheritance -> filter binding... where a filter in our world encompasses a hibernate filter, and a PrePersist and PostLoad listener) I think the view you have on what constitutes a multitenent environment is too narrow. There are a great deal more situations to support and I think many other companies face these issues as we and Damien are. Damien's situation can be solved by what we are doing with filters / persistence listeners. It can be solved better, and more completely, if filters were active on em.find calls. On Wed, Nov 30, 2011 at 8:26 AM, Jason Clawson wrote: > Thanks for your response. Yes it is multi-tenency however that's just > 1 filter of the 8 we have. We use it for more than just that. For > example, within a single customer, there are object visibility > permissions based on a complex interaction between roles and a tree > with inheritance. Whether or not a user can see a particular object > is determined by a recursive tree traversing oracle CONNECT BY clause. > > These different visibility filters we have are only applied to > specific entities. Filters are the right mechanism to handle this as > they contain all the necessary semantics We can disable them for > certain requests if the current user is an admin, or we can even do it > for a few specific queries with our sudo concept. They can be applied > to specific entities and multiple filters can be applied to the same > entity. And since a relatively recent release they affect DML > operations (I had to patch hibernate to do this a while ago). > > The multitenency in 4.0 won't work for us. We have a single schema > based multi tenency. The discrimination based one probably won't work > either because we need to be able to write a custom SQL clause like we > can in filters. It would work for customer data separation probably, > but our other 7 filters can not be modeled in that way since they rely > on some complex SQL clauses. > > I understand filters work as intended. Can you explain a little about > why it was intended to ignore the active filters when doing a find? > And why respecting the filters on a find is bad? > > Thanks, > > Jason Clawson > > > > Sent from my iPhone > > On Nov 30, 2011, at 7:30 AM, Steve Ebersole wrote: > > > What you are doing is called multi-tenancy. > > > > Hibernate 4 has more explicit support for multi-tenant data. > Unfortunately 4.0 only supports cases where the schema is replicated on > multiple databases/schemas. There will also be support for > discrimination-based multi-tenancy at some point in 4.x (4.1 or 4.2). If > you want to help develop that feature, that would be great. > > > > However, I am not going to change the way/places that filters are > applied. They work exactly as intended. > > > > > > On Tue 29 Nov 2011 11:24:19 AM CST, Jason Clawson wrote: > >> Hi everyone. I know that Hibernate session filters do not apply to > >> find/load operations because the assumption was made that if you know > the > >> ID of the entity you wish to load, why tack on the extra WHERE > condition. > >> Please let me explain my use case for filters and illustrate why this > >> assumption is incorrect. > >> > >> We use filters to do data separation. For example, separating one > >> customers data from another's. We also have other filters that do finer > >> grained object visibility conditions. But lets take a look at customer > >> data separation since its the easiest to understand. The advantage of > >> doing customer data separation in this way is that developers don't > need to > >> think about it. It just works, and it works *automatically*. The > problem > >> comes in when you want to do something like em.find(User.class, 1). No > >> WHERE clause is attached to the SQL statement. Yes, I know the ID, but > I > >> really want to tack on to the WHERE clause "AND customerId = 3" to make > >> sure that someone isn't fuzzing the ID parameter to try and get at > another > >> customer's data. > >> > >> The workaround we have is another mechanism that validates the entity > in a > >> PostLoad entity listener and throws an exception if the customerId != > the > >> request's customerId. This is "ok" for
