the documentation for the plugin states
There is no automatic filtering for native SQL so tenants should not have access to any functionality giving access to write native SQL or Groovy code (JMX Console, SQL/Groovy bands in reports etc.) .
However, I have a service exposed through a custom rest controller. In the service I have 2 methods querying the same query. one goes through the entitymanger, the other users the datamanager.
When using the datamanager the entities are correctly filtered out, but when using the entitymanager no filtering is applied.
This is the expected behaviour.
As stated in the addon documentation:
Tenant permissions are handled by CUBA security subsystem
If you take a look at the documentation, there is a section about the differences of entity manager and datamanager.
DataManager checks security restrictions when invoked on the client tier. EntityManager does not impose security restrictions.
I know this is an old topic by now, but I revisited it since I’m working on the api again. In my opinion it is still an issue.
@peterson.br I disagree with your comment,
I am not referring to entity permissions. Permissions have an impact on what operations are allowed on a type of entity. Eg. a user is allowed to create instances of type X. What I am talking about is filtering. I should only see entities belonging to my tenant.
These are 2 orthogonal aspects. The security is defined on a class while the filtering is defined at instance level (or record level if you will)
The fact that de documentation explicitly talks about native queries but not about the distinction between EntityManager and DataManager strengthens my idea that both should apply filtering.
Can anyone from @CUBA tell me the exact behaviour? Either the documentation should be updated or a bug should be created.
Everything that CUBA provides from a security perspective is built on top of the JPA layer. JPA itself is unaware of concepts like entity permission, security constraints etc.
If you are interacting with the JPA layer directly without going through the CUBA abstractions, you will not get its benefits (nor its drawbacks).
As the EntityManager is an Abstraction from JPA, you’ll not get row level security etc.
See also a description on where which security parts from CUBA are applied: Data Access Checks - CUBA Platform. Developer’s Manual
I’ve created ticket to update the documentation: Add mentioning of EntityManager to the documentation · Issue #60 · cuba-platform/multitenancy-addon · GitHub
You are right when saying that current documentation page doesn’t explicitly say that you need to use DataManager if you need to auto-apply multi-tenancy constraints.
The link you gave actually only details permission and security checks at type level but not at record level. For this we would need some additional criteria appended on queries.
While Jpa itself doesn’t have support for adding additional record level criteria both Hibernate (@ Filter, @ FilterDef, @ Where, …) and EclipseLink (@ AdditionalCriteria) provide support for this. This is of course targeted at the JPA entitymanager.
So basically, it is not supported but it could have been. Hence my question to clarify.
Multitenancy applies constraints on the JPA layer using
@ AdditionalCriteria doesn’t work with native SQL queries.
@subbotin That’s what I expected, hence I asked for clarification. But your answer is contradicting mario and @AlexBudarov.
@subbotin answer states that com.haulmont.cuba.core.EntityManager takes multitenancy into account.
Mario and @AlexBudarov are both saying it only works for datamanager.
the documentation is not saying anything.
We’ll update the documentation: Add mentioning of EntityManager to the documentation · Issue #60 · cuba-platform/multitenancy-addon · GitHub
Multitenancy addon has applied constraints on EntityManager layer since the 7.2 version.
- Adding multitenancy constraints work on the EntityManager layer for JPQL queries. Multitenancy constraints don’t work for native SQL queries.
- If you need auto-applying of tenant constraints, you need to load data with EntityManager/DataManager
- All data loaders use DataManager to load their data
- REST API also uses DataManager to load data
- Reporting: SQL bands don’t apply multitenancy constraints. Those can be applied only if you call DataManager queries inside of a Groovy band or use JPQL bands.
- Reporting: JPQL bands work with multitenancy constraints.
@subbotin thanks for the clarification.
I guess my initial expectations where correct but only implemented in 7.2.
At least now everything is well-defined.