Intercept repository method calls in Spring Data, refining the query on the fly

Question

Say I've got a few interfaces extending CRUDRepositor. There are methods in there like findByField. Some of these methods should only return entities that belong to a group of entities to which the user has access (the group is a column in the database, so it's a field that's defined for most entities). I want to achieve this by allowing the use of annotations (like @Protected) on the repository methods, and then when these methods are called instead of calling findByField a method findByFieldAndGroup is called behind the scenes. With the use of AOP (which intercepts methods annotated with my @Protected tag) the group can be assigned before the method is effectively executed.

public interface MyRepository extends CRUDRepository<MyEntity,long> {

    @Protected
    Optional<MyEntity> findById(Long id); // Should become findByIdAndGroup(Long id, String group) behind the scenes

    @Protected
    Collection<MyEntity> findAll();

}

Is there a way to achieve this? In the worst case I either add all the methods manually, or completely switch to a query by example approach (where you can more easily add the group dynamically) or generate methods with a Java agent using ASM (manipulating the bytecode) ... but these are much less practical approaches which demand a good deal of refactoring.

Edit : found these relevant questions Spring data jpa - modifying query before execution Spring Data JPA and spring-security: filter on database level (especially for paging) Other relevant references include this ticket on GitHub (no progress, only a sort-of-solution with QueryDSL which precludes the use of queries based on method names) and this thread.

Answer 1

You can use filters, a specific Hibernate feature, for this problem.

The idea is the following.

First, you need to annotate your entity with the different filters you want to apply, in your case, something like:

@Entity
//...
@Filters({
  @Filter(name="filterByGroup", condition="group_id = :group_id")
})
public class MyEntity implements Serializable { 
  // ...
}

Then, you need access to the underlying EntityManager because you need to interact with the associated Hibernate Session. You have several ways to do this. For example, you can define a custom transaction manager for the task, something like:

public class FilterAwareJpaTransactionManager extends JpaTransactionManager {

  @Override
  protected EntityManager createEntityManagerForTransaction() {
    final EntityManager entityManager = super.createEntityManagerForTransaction();
    // Get access to the underlying Session object
    final Session session = entityManager.unwrap(Session.class);

    // Enable filter
    try{
      this.enableFilterByGroup(session);
    }catch (Throwable t){
      // Handle exception as you consider appropriate
      t.printStackTrace();
    }

    return entityManager;
  }

  private void enableFilterByGroup(final Session session){
    final String group = this.getGroup();

    if (group == null) {
      // Consider logging the problem
      return;
    }

    session
      .enableFilter("filterByGroup")
      .setParameter("group_id", group)
    ;
  }

  private String getGroup() {
    // You need access to the user information. For instance, in the case of Spring Security you can try:
    final Authentication authentication = SecurityContextHolder.getContext().getAuthentication();

    if (authentication == null) {
      return null;
    }

    // Your user type
    MyUser user = (MyUser)authentication.getPrincipal();
    String group = user.getGroup();
    return group;
  }
}

Then, register this TransationManager in your database configuration instead of the default JpaTransactionManager:

@Bean
public PlatformTransactionManager transactionManager() {
  JpaTransactionManager transactionManager = new FilterAwareJpaTransactionManager();
  transactionManager.setEntityManagerFactory(entityManagerFactory());
  return transactionManager;
}

You can also have access to the EntityManager and associated Session by creating a custom JpaRepository or by injecting @PersistenceContext in your beans, but I think the above-mentioned approach is the simpler one although it has the drawback of being always applied.