spring-data-jpa
spring-data-jpa copied to clipboard
spring-projects
Update documentation to demonstrate using RepositoryFactoryCustomizer
Thomas Darimont opened DATAJPA-562 and commented
A common requirement that users have is to be able to inspect and / or modify objects after they are returned by the EntityManager before they are passed on to the user code. Therefore it would be helpful to have a pluggable way to generically post-process query results, e.g. to automatically detach result entities or do some additional security checks, mask some data etc
Affects: 1.6 GA (Dijkstra)
Issue Links:
-
DATAJPA-564 Support for SpEL based parameter expressions in repository query methods
-
DATAJPA-565 Support for referencing Spring Security information in queries
Referenced from: pull request https://github.com/spring-projects/spring-data-jpa/pull/99, and commits https://github.com/spring-projects/spring-data-jpa/commit/256978eee64089c41666397efbc51e3abc641090, https://github.com/spring-projects/spring-data-jpa/commit/c0d950cdb78a70981894760c3fbd7c403600df7c, https://github.com/spring-projects/spring-data-jpa/commit/8ee183c79939167aed37cb76dc94388dc89e1c72
2 votes, 6 watchers
Oliver Drotbohm commented
What's the purpose of this? The sample implementations look rather artificial and I have a hard time thinking of a real-world use case. So some clarification would be helpful
Pedro Robles commented
Hi Oliver,
On one of the projects I'm working at this moment, we store bank accounts encrypted on the db. Hibernate allows to implement it through custom interceptors.
Hope this helps.
Oliver Drotbohm commented
The issue is part of an implementation approach for DATAJPA-565. We've identified a few issues with it and it seems that we're likely about to pursue an alternative solution for the problem this particular ticket was actually intended to solve
Rob Winch commented
A few concrete use cases we had were:
-
Allowing Spring Security to clear out or post process sensitive values (quite similar to what Pedro Robles is describing). If done in commons, this would allow for hashing and encrypting of values as requested in DATAMONGO-874
-
Allow to detach the Entities. This can be used in a few circumstances.
-
Many times users do not want entities to be attached as this can cause unintentional side effects in the database. Many users like to have to explicitly call a save operation rather than having something automatically save the domain object when it has been modified.
-
When securing the repository today we can easily add Spring Security's
@PreAuthorizeannotation to any write methods. However, this does not work if the entity's are still attached since modifying a result that has been returned can write to the Database. Admittedly, this is only one way of achieving such functionality, so I'd be quite welcome to other implementations that would achieve the same outcome
Robin Jonsson commented
Bumping & Voting for this. I can imagen a lot of use cases for an interceptor on a repository level. I think this would be a really kick-ass feature of Spring Data, to intercept entities/model obj, disregarding underlaying storage (JPA, Mongo, etc) before returning to calling class.
Regards
Post processing results from the EntityManager has huge risks. Due to JPA's proxy-based, mutable nature, masking data values could cause alterations to the database itself on the next commit. It also risks contracts such as return a Page that had 50 elements, but for some reason now has 49 due to security filter.
Instead, this issue can be used to enhance the ref docs showing how users can hook into Spring Data Commons's RepositoryFactoryCustomizer, which affords multiple things including some variants of post processing.
