Allow multiple repositories per entity (only one should be exported) [DATAREST-923]

[spring-projects-issues]

Tim Meißner opened DATAREST-923 and commented

My case is that i have an Entity "User" and two Repositories:

• UserRepository extends CrudRepository, @RepositoryRestResource(exported = false): meant for internal usage by services etc.
• UserRestRepository extends Repository, @RepositoryRestResource(exported = true): meant for external usage, restricted access, etc.

This exports a user resource in 50% of the times i start up the application. I tried to work around this by annotating them with @Order(0/1) for the UserRepository and @Order(1/0) for the UserRestRepository, but it doesn't work.

So I would like to have the possibility to have multiple Repositories for one entity (only one exported but it should not conflict with other normal Repositories that are not exported).

---

Affects: 2.5.4 (Hopper SR4)

Reference URL: http://stackoverflow.com/questions/36112451/multiple-repositories-for-the-same-entity-in-spring-data-rest

Issue Links:

• DATACMNS-1448 Repositories should select primary repository in case multiple are available for a domain type
  ("depends on")

Referenced from: pull request spring-projects/spring-data-commons#465, and commits spring-projects/spring-data-commons@de7a7ca, spring-projects/spring-data-commons@d8705c1

40 votes, 40 watchers

[spring-projects-issues]

Oliver Drotbohm commented

Generally speaking SD REST expects one repository per domain type. You can disambiguate the situation by making one @Primary. Would you mind elaborating what's behind the idea to use two different types?

[spring-projects-issues]

Tim Meißner commented

Sure, so basically I am implementing a User Account Settings page - a user should be able to edit his own entity, so I use method security to disallow saving user entities with a different username than the principal. On the other hand there might be an admin user which can trigger service methods over a custom controller that might change other user entities than himself. If i use the same repository the access control will prevent the admin from doing that, so it's good to have two in this case. A complicated security expression / service call might not be enough in this situation, because i could also need to change other users as a normal user by calling other business related services.

@Primary doesn't bring the desired result, i tried with one Repository but as soon as i have @PreAuthorize it requires me to have an Authentication in the SecurityContext which means i can't use the Repo in a CommandLineRunner for example

[spring-projects-issues]

Daniel Wegener commented

Imo not a minor - once you provide more than one repository for an entity type, the behaviour of the application changes randomly, depending on which repository is found in the bean factory first (and this seem to change from compile to compile run). Took me a day to figure out why this is happening (I'd second a comment on Stackoverflow, it should at least yield a warning on the log).

My use case:
I have two distinct JpaRepository for a single type. One to be exposed by spring data rest (using @PreAuthorize annotations) and one to be used by other internal controllers (which have no spring security context (yet) - in my case the spring security oauth ClientDetailsService)

[spring-projects-issues]

Oliver Drotbohm commented

Daniel Wegener — Does the workaround with @Primary work for you?

[spring-projects-issues]

Daniel Wegener commented

Hi Oliver. The workaround does not work in this case since they are distinct repositories:

@RepositoryRestResource
public interface ClientRepository extends JpaRepository<Client, String> { // with @PreAuthorize overwritten accessors

and

@RepositoryRestResource(exported = false)
public interface InternalClientRepository extends JpaRepository<Client, String> {}

From what I understand: Since none of them is a subtype of the other, there is no ambiguity that could be resolved with @Primary. Both pass org/springframework/data/spring-data-commons/1.12.2.RELEASE/spring-data-commons-1.12.2.RELEASE-sources.jar!/org/springframework/data/repository/support/Repositories.java:93 and the last one for the same entity name simply wins. The @Primary does not seem to affect the order in which they pass through it.

[spring-projects-issues]

Oliver Drotbohm commented

I see. I guess we need Repositories to leniently collect all repositories first, then allow a lookup with a dedicated selection criteria with the current implementations expecting either a canonical reference and throwing an exception on ambiguities. Spring Data REST could then use a custom RepositoryInvoker that applies a criteria (e.g. the presence of @RepositoryRestResource) to select the interface it's interested in

[spring-projects-issues]

benkuly commented

Is there any workaround?

[spring-projects-issues]

Johannes Hiemer commented

Having exactly the same issue and the same requirements:

• One set of repositories where you have all the security annotations for the public REST endpoint
• One set of repositories for internal handling of data access

Is there any update, when this will be solved?

[spring-projects-issues]

Istvan Ratkai commented

Exactly the same issue here. One repository for public usage, one for internal usage without security + some extra methods

[spring-projects-issues]

Johannes Hiemer commented

I would pick up again on this issue, as I don't see why it is prioritised with "minor". To secure an application is substantially important to have mechanism of not maintaining the same repositories two times for different purposes - one of applications with external access to the data via REST and one for the internal access.

So my question: if this is not possible on the repository implementation level, is there any useful workaround on the SpelEvaluationContext?

[spring-projects-issues]

Will Faithfull commented

I also think this is the simplest solution to secure repositories - I would also agree that it should be more than "minor". Relying on @PreAuthorize on repository methods to secure requests is causing me no end of headaches. Not least when I bootstrap the database in a CommandLineRunner with no authentication in the context. I am currently exploring an ugly hack to get the control I want over security, with Aspects around the spring-data-rest controllers. That is too ugly and brittle to move forward with though

[spring-projects-issues]

Will Faithfull commented

Inspired by the suggestion by Oliver above, I have arrived at an acceptably solid hack for the time being. Rather than using the RepositoryRestConfigurerAdapter for my configuration, I subclass RepositoryRestMvcConfiguration to the same end. That allows me to override the repositories() factory method with a subclassed implementation of Repositories, which prioritises repositories which have @RepositoryRestResource(exported=true) on the repository interface.

This means I can define, for example

@RepositoryRestResource(exported = false)
public interface InternalUserRepository extends BaseRepository<User, UUID> {
...
}

@RepositoryRestResource(path = "users")
@PreAuthorize("hasRole('ADMINISTRATOR')")
public interface UserRepository extends BaseRepository<User, UUID> {
...
}

etc. If I want to allow a signup by an anonymous principal, I can handle that insertion through a custom route, with my InternalUserRepository. Due to the correct prioritization in Repositories, all the exported repositories are correctly managed by spring data rest

[spring-projects-issues]

Johannes Hiemer commented

@Will would you mind sharing your workaround? I had no time to look into it, but I would be highly interested.

[spring-projects-issues]

Oliver Drotbohm commented

I guess UserRepository in his example is additionally annotated with @Primary. Note, that you can just drop public from InternalUserRepository to prevent it from being exported, too. If it's for internal use, you most likely would want to use it from outside the package anyway but rather expose some more high-level service

[spring-projects-issues]

Will Faithfull commented

@Johannes I've thrown together a sample on github here. It feels like quite a dirty workaround, but it does the job in the mean time. @Oliver yes, I presume it will follow whatever the configured repository detection strategy is. I would be intending to use it as part of a UserService or such anyway