Push security filters into DB

[jmoore]

Currently, our filtering is done in the business logic (for all intents and purposes). It should be possible to push that down into the Hibernate-generated SQL queries. Filters are the name of the game.

The main concern is whether or not our queries begin to behave differently once this is put in place. Outer joins may not begin to behave as inner joins as was happening in Omero2.

[jmoore]

Vital for read security.

[jmoore]

Read filters can only be applied to "Global" types with difficult because of the missing owner_id, group_id, and creation_id columns. See #230.

[jmoore]

Won't be sufficient. Will also need catches in OmeroInterceptor onLoad.

See http://opensource.atlassian.com/projects/hibernate/browse/HHH-67

[jmoore]

r789 has this working. There need to be extensive tests regarding joins (there are already some interesting issues regarding the one-to-one between Image and Pixels), but by and large, yes, we now filter directly in the DB.

The actual filter is defined in code (SecurityFilter) to make use of SecuritySystem methods (#225). The actual enabling of the this happens in EventHandler (already updated in r787). However, #232 will need to be addressed for this to be fully "safe".

---

Note: SaveEventSupport should have been in r788.

[jmoore]

r793 patches the spring-hibernate3-2.0-rc1.jar (from 2.0-rc2 code) to fix a Hibernate configuration issue. This is written up as:

http://opensource.atlassian.com/projects/spring/browse/SPR-2305

[jmoore]

r796 patches another spring jar (see #238) and adds mock_filters.hbm.xml to allow build to get past the Hibernate bug mentioned in SPR-2305

[jmoore]

r810 add the jars again. Something was fishy.

[jmoore]

r823 addsd the SecurityFilter to all collections. This was missing before but very important.

[jmoore]

Unscheduling this umbrella ticket.

[jmoore]

Merging with #200.