Spring Data REST Override findBy* Method

Question

I am using spring-data-rest-webmvc 2.0.0.RELEASE w/ spring-data-jpa 1.5.0.RELEASE.

I have a RoomRepository, RoomRepositoryCustom, and RoomRepositoryImpl class.

I am trying to override a findBy* method so that I can provide custom logic to do the work of @PostFilter, but return paginated results.

I originally had this in RoomRespository:

@PostFilter("hasPermission(filterObject, '" + FIND + "')")
@RestResource(rel = "byName", path = "byName")
public List<Room> findByName(@Param("name") String name);

It works well, but due to limitations on @PostFilter I must return a List and cannot return a Page.

I'd like do away with @PostFilter like this:

@RestResource(rel = "byName", path = "byName")
public Page<Room> findByName(@Param("name") String name, Pageable p);

But I still need to filter my results by the authenticated user's principal. (Which I hoped to do in my custom method)

So I figured that I could override findByName by providing an implementation in RoomRespositoryImpl, but that doesn't appear to work properly. If I attempt to override findByName then Spring Data REST no longer picks up the method and never registers an endpoint for rooms/search/byName?name="test".

I also tried using @Query to define a custom query for the finder. It works, but I don't believe it will work for my purposes since I need to use the authenticated user's principal as a query parameter.

In summary: How best to go about implementing a /rooms/search/byName?name="test" endpoint with Spring Data REST that returns a Page of rooms with names that contain the parameter, but is also filtered by my own custom logic based on looking up the currently authenticated user's permissions in a separate table?

Is there a way to add a custom link under /rooms/search/* ?

Answer 1

In short: this is currently (version 2.0/2.1) not supported. Pagination is quite a complicated beast when it comes to security as an @PostFilterapproach doesn't really work due to the fact that you'd create invalid results if you filtered items from the page after it has been loaded.

A correct solution to this issue requires the security constraint being incorporated into the query executed. We have a ticket in Spring Data Commons to keep track of the general infrastructure required for this, as well as a somehow related one on the support for soft deletes in Spring Data JPA which you might wanna track on progress on that topic.