Add row-level security filter in query #17564

cecemei · 2024-12-13T02:21:52Z

This PR adds the ability to attach restrictions (e.x. row filters) to a query, thus restrict row-level data access for given users. Note that this feature is not directly available, and requires additional work in Authorizer.

This PR has been tested in a local druid cluster with additional Authorizer changes.

Description

A query follows these steps: initialize -> authorize -> execute. In the authorize step, the permissions are checked for all the required resources in the query. Before this PR, the authorize step only returns allow or deny access on a table. Granting access to a table means a user can see all data in this table. After this PR, the authorize step can return allow access along with restrictions (i.e. a row filter that must be applied to the table ), which restrict users' data access at row level. For example, customers can only see rows relevant to their company.

The authorizeAllResourceActions now returns a AuthorizationResult instead of Access. The main difference between AuthorizationResult and Access is that the former contains a map of table with restriction (i.e. Policy)

In the authorize step of QueryLifecycle, it would add the Policy to tables in the datasource tree, transform TableDataSource to RestrictedDataSource. In the execute step, Policy is enforced through RestrictedSegment and RestrictedCursorFactory, the filter inside Policy would be attached to the CursorHolder.

Key changed/added classes in this PR

Policy interface and subclasses.
- a Policy represents granular restrictions when reading tables.
- NoRestrictionPolicy should be used by druid-internal and superuser.
- RowFilterPolicy is a basic row filter restriction.
Access. Added Optional<Policy> policy field, which represents a restrictions returned from authorizer. Also updated constructor.
AuthorizationResult. The class should be used for all the authorization calls, while the Access class is still used in Authorizer interface. It has an static variable ALLOW_NO_RESTRICTION, which should be used for all internal calls. The class contains:
- permission, an enum defines the permission check result.
- failure message if authorization deny access. This is null when auth is allowed, and is the error message of the first resource action authorization failure (there might be more failures, but we don't try further)
- a map of table name with optional policy.
AuthorizationUtils. It now consolidates all restrictions for authorizing resource actions into a restrictions map, which is included in AuthorizationResult. Also updated javadoc for all public methods.
RestrictedDataSource, which wraps a TableDataSource with a Policy.
RestrictedSegment, which represents a segment with a policy.
BypassRestrictedSegment, a backdoor to retrieve the wrapped segment and policy from RestrictedSegment.
RestrictedCursorFactory, enforces the policy on Cursor.
DataSource interface, added a sub type of restrict, added a default method mapWithRestriction. Also:
- TableDataSource, added the implementation of mapWithRestriction.
- JoinDataSource can accept RestrictedDataSource as left-hand side datasource.
QueryLifeCycle, replace baseQuery with baseQuery.withPolicyRestrictions (except for SegmentMetadataQuery).

Caveats

The restrictions don't apply to VIEWs.
UnionDataSource doesn't work with RestrictedDataSource, planning to fix that later.
The restrictions don't apply to DartQueryMaker and MSQTaskQueryMaker, for now they would throw an error if there's any policy restrictions.
In some places the access check might be overly-restrictive (e.x. cancel query).

This PR has:

been self-reviewed.
- using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
[] added documentation for new or modified features or behaviors.
a release note entry in the PR description.
added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
added or updated version, license, or notice information in licenses.yaml
added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
added integration tests.
been tested in a test Druid cluster.

processing/src/test/java/org/apache/druid/query/RestrictedDataSourceTest.java

…it as the default interface for checking permission

…field now

indexing-service/src/main/java/org/apache/druid/indexing/overlord/http/OverlordResource.java

          resourceAction,
          authorizerMapper
      );
-      if (!authResult.isAllowed()) {
+
+      authResult.getPermissionErrorMessage(true).ifPresent(error -> {


gianm

This review includes some high level design comments.

I haven't checked the tests yet (will do so in a follow up review). The things I'd be looking for in the tests are:

we should have tests for the resources, including negative tests for resources (such as the Dart resource) that don't support policies yet. The negative tests should verify that we get an error like "this endpoint doesn't support policies".
we should also have tests for the lower level pieces like QueryLifecycle, the DataSource mapping, and RestrictedSegment.

server/src/main/java/org/apache/druid/server/security/AuthorizationResult.java

server/src/main/java/org/apache/druid/server/QueryLifecycle.java

server/src/main/java/org/apache/druid/server/security/AuthorizationUtils.java

server/src/main/java/org/apache/druid/server/security/Access.java

processing/src/main/java/org/apache/druid/query/RestrictedDataSource.java

processing/src/main/java/org/apache/druid/query/DataSource.java

processing/src/main/java/org/apache/druid/segment/RestrictedSegment.java

…AuthorizationResult class, dart sql, msq sql, fix bug, added restricted data source to calcite test data

extensions-core/multi-stage-query/src/test/java/org/apache/druid/msq/exec/MSQSelectTest.java

@@ -798,6 +799,20 @@

  }

+  @MethodSource("data")
+  @ParameterizedTest(name = "{index}:with context {0}")
+  public void testSelectRestricted(String contextName, Map<String, Object> context)


…rityLevel enum in Policy class, updated a bunch of tests

…internal won't be restricted

LakshSingla · 2025-01-06T06:22:12Z

processing/src/main/java/org/apache/druid/query/RestrictedDataSource.java

+    if (!(base instanceof TableDataSource)) {
+      throw new IAE("Expected a TableDataSource, got [%s]", base.getClass());
+    }
+    if (Objects.isNull(policy)) {
+      throw new IAE("Policy can't be null for RestrictedDataSource");


Passer-by nits:

It is better to use DruidExceptions instead of IAE/ISE. That would inform the readers as to whom the error message is intended for. It also guides the wording of the error message. Currently, it is not actionable. It is fine if the check is defensive, but if it is a user-facing error it would be nice to word it in a way that's easier for users to understand/take action upon.

The interpolations [] can be in a different manner, where the exception is still understandable even if the interpolated phrases are removed, like: "Incorrect datasource [%s] received, expected a TableDataSource"

abhishekagarwal87 · 2025-01-07T08:24:45Z

extensions-core/druid-catalog/src/main/java/org/apache/druid/catalog/http/CatalogResource.java

-      throw new ForbiddenException(authResult.toString());
-    }
+    final AuthorizationResult authResult = authorizeAccess(resource, key, action, request);
+    authResult.getPermissionErrorMessage(true).ifPresent(error -> {


its weird that we throw a 401 if there is a permission error message. There should be a function available in AuthorizationResult to directly return a boolean indicating whether user is authorized or not.

server/src/main/java/org/apache/druid/server/security/AuthorizationResult.java

server/src/main/java/org/apache/druid/server/security/AuthorizationUtils.java

gianm · 2025-01-07T16:58:04Z

processing/src/main/java/org/apache/druid/query/RestrictedDataSource.java

+public class RestrictedDataSource implements DataSource
+{
+  private final TableDataSource base;
+  private final Policy policy;


I think this would work better as a List<Policy> rather than a single Policy. And Policy should be an interface with the contract that each type of policy is never refined to have more security-relevant information. Instead, a new subclass should be created.

The reason is that one day we will want to add new kinds of policies, such as column-level filters. It's not going to work well to add them to this existing Policy object, because it'll be difficult to ensure they are actually checked in all the correct places. (Some of those places may even be query types in third-party extensions.) The design needs to "blow up" if a new policy type is added that existing callers don't know about.

The list-of-policies achieves this, because if an existing caller encounters a Policy of a type it does not recognize, it can throw an exception.

thank i didn't think about that before - planning to change Policy to be an interface and add RowFilterPolicy and NoRestrictionPolicy subclass.

I still think this should be a List, otherwise auth extensions are going to have to some work to what might logically be multiple policies (in the general sense at least). Like imagine an auth setup like ldap or something where there are users and groups that allows defining policies at both levels, if we don't allow a list here than that extension would have to combine all of that stuff into a single Policy.

Maybe that is fine I guess, but it does seem like it would make extensions have to do more work instead of just mapping different logical types of policies such as row filtering and column access into a single CursorBuildSpec transformation. I guess the benefit of a single policy would be that if there were multiple row filters in place for example it could be combined into a flat and statement instead of like a = 'x' && (b = 'y' && c = 'z').

Policies may come from multiple sources, and all need to be combined together by Authorizers. So, this either needs to be List<Policy> or we need to have an AndPolicy that can wrap multiple policies.

IMO, List<Policy> is cleaner since it makes it easier to write code that combines policies and code that walks through policies. With a List, that's just adding elements to a list or iterating a list. With Policy, combining two policies would require creating a new AndPolicy (and checking the input policies to see if they are already AndPolicy; & if so, flattening them.) Walking through policies would require an instanceof AndPolicy check.

So my vote is to go with List<Policy> here.

gianm · 2025-01-07T17:26:52Z

processing/src/main/java/org/apache/druid/segment/RestrictedSegment.java

+{
+  protected final SegmentReference delegate;
+  @Nullable
+  private final DimFilter filter;


This should be a List<Policy> just like in RestrictedDataSource, and for the same reasons: #17564 (comment)

gianm · 2025-01-07T19:08:07Z

processing/src/main/java/org/apache/druid/segment/RestrictedSegment.java

+
+  @Nullable
+  @Override
+  public <T> T as(@Nonnull Class<T> clazz)


There's a problem here: some query engines use QueryableIndex for direct access to columns and indexes, and we can't really make a clean restricted wrapper around QueryableIndex (we can't anticipate what columns and indexes may occur in extensions). So we need some way for query engines to say "give me the QueryableIndex, I know what I'm doing and I will apply the policies directly".

IMO, a good way to do that is to offer an as(BypassRestrictedSegment.class) which returns one of these:

class BypassRestrictedSegment implements SegmentReference { private final Segment segment; private final List<Policy> policies; public List<Policy> getPolicies() { return policies; } @Override public CursorFactory asCursorFactory() { // Bypass policies return delegate.asCursorFactory(); } @Override public <T> T as(Class<T> clazz) { // Bypass policies return segment.as(clazz); } }

Policy-aware query engines that need to use QueryableIndex directly are expected to:

Call as(QueryableIndex.class) first.

If that returns null, try as(BypassRestrictedSegment.class) followed by as(QueryableIndex.class).

Call getPolicies() and apply the policies when using the QueryableIndex.

Throw an exception if any unrecognized policies are found.

Call as(QueryableIndex.class) first.
If that returns null, try as(BypassRestrictedSegment.class) followed by as(QueryableIndex.class)

I was thinking that maybe this should throw an exception targeted at developers to indicate that they should call as(BypassRestrictedSegment.class), since imagining in the future if this were rolled out with some policies then the .as/asQueryableIndex methods would go from working to suddenly returning null.

Along with throwing an exception, would also maybe a helper method to indicate if the segment supports BypassRestrictedSegment, though the same could also work if we just return null from .as, so I don't feel too strongly either way.

exception targeted at developers to indicate that they should call as(BypassRestrictedSegment.class)

I was thinking that query engines might have fall-back code to do something cursor-based if QueryableIndex isn't available. They would need this anyway if they wanted to work on real-time data. Returning null in these cases lets the fall-back code activate.

gianm · 2025-01-07T19:09:20Z

processing/src/main/java/org/apache/druid/query/policy/Policy.java

+/**
+ * Represents a granular-level (e.x. row filter) restriction on read-table access.
+ */
+public class Policy


For reasons in https://github.com/apache/druid/pull/17564/files#r1905784938, this should be an interface rather than a class.

clintropolis · 2025-01-07T19:52:37Z

processing/src/main/java/org/apache/druid/segment/RestrictedSegment.java

+
+  @Nullable
+  @Override
+  public <T> T as(@Nonnull Class<T> clazz)


Call as(QueryableIndex.class) first.
If that returns null, try as(BypassRestrictedSegment.class) followed by as(QueryableIndex.class)

I was thinking that maybe this should throw an exception targeted at developers to indicate that they should call as(BypassRestrictedSegment.class), since imagining in the future if this were rolled out with some policies then the .as/asQueryableIndex methods would go from working to suddenly returning null.

Along with throwing an exception, would also maybe a helper method to indicate if the segment supports BypassRestrictedSegment, though the same could also work if we just return null from .as, so I don't feel too strongly either way.

clintropolis · 2025-01-07T19:55:34Z

server/src/main/java/org/apache/druid/server/security/Access.java


  private final boolean allowed;
  private final String message;
+  // A policy restriction on top of table-level read access. It should be empty if there are no policy restrictions
+  // or if access is requested for an action other than reading the table.
+  private final Optional<Policy> policy;


re other comments about lists, this should also be a list of Policy

server/src/main/java/org/apache/druid/server/security/AuthorizationResult.java

server/src/main/java/org/apache/druid/server/security/Policy.java

…icy class. Updated AuthorizationResult class as well.

server/src/test/java/org/apache/druid/initialization/AuthorizationResultTest.java

…olicy subclasses

clintropolis

did another pass, still thinking about some things so will keep looking over stuff

clintropolis · 2025-01-08T22:52:49Z

server/src/main/java/org/apache/druid/server/QueryResource.java

+    if (!authResult.isUserWithNoRestriction()) {
+      throw new ForbiddenException(authResult.getErrorMessage());


I'm not sure this is correct, since it would prevent users with policies from cancelling their own queries

This is weird but it is difficult to do something better without deeper changes to cancellation authorization. Ideally the way it works is that people are only allowed to cancel their own queries, unless they have STATE WRITE, in which case they should be able to cancel any query. But that's not how cancellation works today, because we don't retain info about which user issued a query.

IMO, it'd be good to adjust this in a follow up, so we can change things so it works like the above ☝️. For the time being I think it is OK to err on the secure side, which means denying cancellation to people with policies.

server/src/main/java/org/apache/druid/server/QueryResource.java

clintropolis · 2025-01-08T23:04:52Z

server/src/main/java/org/apache/druid/server/security/AuthorizationResult.java

+   * <li> no policy found
+   * <li> the user has a no-restriction policy
+   */
+  public boolean isUserWithNoRestriction()


naming nit, there is no such thing as a "user" in Druid core, that is a construct that may or may not exist in specific auth extensions.

Beyond that, I'm not quite sure this is the correct model, is it overly restrictive since many of the former callers of isAllowed are calling this, it seems like if there are any policies involved at all then the only thing that will be allowed is query calls, every other API would be disallowed, which doesn't seem the best behavior to me.

clintropolis · 2025-01-08T23:11:46Z

processing/src/main/java/org/apache/druid/query/RestrictedDataSource.java

+public class RestrictedDataSource implements DataSource
+{
+  private final TableDataSource base;
+  private final Policy policy;


I still think this should be a List, otherwise auth extensions are going to have to some work to what might logically be multiple policies (in the general sense at least). Like imagine an auth setup like ldap or something where there are users and groups that allows defining policies at both levels, if we don't allow a list here than that extension would have to combine all of that stuff into a single Policy.

Maybe that is fine I guess, but it does seem like it would make extensions have to do more work instead of just mapping different logical types of policies such as row filtering and column access into a single CursorBuildSpec transformation. I guess the benefit of a single policy would be that if there were multiple row filters in place for example it could be combined into a flat and statement instead of like a = 'x' && (b = 'y' && c = 'z').

…est for SegmentMetadataQuery.

…uld work with basic access.

gianm · 2025-01-09T15:43:59Z

processing/src/main/java/org/apache/druid/query/policy/NoRestrictionPolicy.java

+{
+  public static final NoRestrictionPolicy INSTANCE = new NoRestrictionPolicy();
+
+  @JsonCreator


for singletons, you can do a public static NoRestrictionPolicy instance() method and annotate that with @JsonCreator. Then Jackson will return the singleton rather than creating a new instance with the constructor.

gianm · 2025-01-09T15:45:14Z

processing/src/main/java/org/apache/druid/query/policy/Policy.java

+   *   <li>{@code POLICY_CHECKED_ON_ALL_TABLES_POLICY_MUST_EXIST}, every table must have a policy when requests come from external users.
+   * </ol>
+   */
+  enum TablePolicySecurityLevel


Let's please remove this and do something similar in a follow up PR. I think some more iteration will be useful on how strictness works, and it'll be easier to that stuff in its own PR.

gianm · 2025-01-09T15:45:49Z

processing/src/main/java/org/apache/druid/query/policy/RowFilterPolicy.java

+  @JsonCreator
+  RowFilterPolicy(@Nonnull @JsonProperty("rowFilter") DimFilter rowFilter)
+  {
+    this.rowFilter = rowFilter;


verify here that rowFilter is nonnull, using Preconditions.checkNotNull

gianm · 2025-01-09T18:12:52Z

processing/src/test/java/org/apache/druid/query/policy/RowFilterPolicyTest.java

+import org.junit.Before;
+import org.junit.Test;
+
+public class RowFilterPolicyTest


Also include a serde test (round trip through JSON) and equals test (using EqualsVerifier).

gianm · 2025-01-09T18:14:04Z

processing/src/main/java/org/apache/druid/query/policy/RowFilterPolicy.java

+public class RowFilterPolicy implements Policy
+{
+  @JsonProperty("rowFilter")
+  private final DimFilter rowFilter;


typically, rather than having Jackson use the private fields directly, we create a getter and annotate the getter with @JsonProperty. Please make that change here.

gianm · 2025-01-09T22:27:51Z

processing/src/main/java/org/apache/druid/query/policy/Policy.java

+    @JsonSubTypes.Type(value = RowFilterPolicy.class, name = "row"),
+    @JsonSubTypes.Type(value = NoRestrictionPolicy.class, name = "noRestriction")
+})
+public interface Policy


Please add @UnstableApi to this interface to emphasize that it might change as we evolve it.

gianm · 2025-01-09T22:29:57Z

server/src/main/java/org/apache/druid/server/security/AuthorizationResult.java

+                                                                  && policyRestrictions.values()
+                                                                                       .stream()
+                                                                                       .map(p -> p.orElse(null))
+                                                                                       .filter(Objects::nonNull) // Can be replaced by Optional::stream after java 11


we do require Java 11 now, so this can be written using Java 11 functions.

gianm · 2025-01-09T22:33:08Z

server/src/main/java/org/apache/druid/server/security/AuthorizationResult.java

+    }
+  }
+
+  public Map<String, Optional<Policy>> getPolicy()


3 notes:

It would be clearer to name this getPolicyMap().

Please include javadoc, since it's not obvious what the keys are.

The value should be a List<Policy> rather than Optional<Policy>.

gianm · 2025-01-09T23:21:43Z

server/src/main/java/org/apache/druid/server/QueryLifecycle.java

@@ -155,10 +162,6 @@ public <T> QueryResponse<T> runSimple(
    final QueryResponse<T> queryResponse;
    try {
      preAuthorized(authenticationResult, authorizationResult);
-      if (!authorizationResult.isAllowed()) {


Why remove this? What happens now if a request is not authorized?

gianm · 2025-01-09T23:22:50Z

sql/src/test/java/org/apache/druid/sql/http/SqlResourceTest.java

@@ -2184,7 +2184,7 @@ private TestHttpStatement(
    @Override
    protected void authorize(
        DruidPlanner planner,
-        Function<Set<ResourceAction>, Access> authorizer


Please add some tests that use Policies to this class.

Please also include tests for the SqlTaskResource endpoint.

github-actions bot added Area - Batch Ingestion Area - Querying Area - Segment Format and Ser/De Area - Ingestion Area - MSQ For multi stage queries - https://github.com/apache/druid/issues/12262 labels Dec 13, 2024

cecemei force-pushed the security2 branch from 85bb1f7 to 652a95c Compare December 13, 2024 04:34

add row-level security filter

3eb0b66

cecemei force-pushed the security2 branch from 652a95c to 3eb0b66 Compare December 13, 2024 19:44

github-advanced-security bot found potential problems Dec 13, 2024

View reviewed changes

processing/src/test/java/org/apache/druid/query/RestrictedDataSourceTest.java Fixed Show fixed Hide fixed

cecemei marked this pull request as ready for review December 13, 2024 20:45

clintropolis added the Design Review label Dec 13, 2024

Add getPermissionErrorMessage method to AuthorizationResult, and use …

dd251c2

…it as the default interface for checking permission

cecemei force-pushed the security2 branch from 925b01f to dd251c2 Compare December 18, 2024 03:30

cecemei added 4 commits December 17, 2024 20:14

policy change

b19728b

minor change, Optional.stream is not supported java8

aae0bb1

Merge remote-tracking branch 'apache/master' into security3

c7dc930

update test case for JoinDataSource since it has a new JoinAlgorithm …

af51747

…field now

cecemei force-pushed the security2 branch from b19728b to af51747 Compare December 18, 2024 06:24

github-advanced-security bot found potential problems Dec 18, 2024

View reviewed changes

cecemei added 2 commits December 18, 2024 00:11

fix a bug in AuthorizationResult

92077ed

fix style and bug

a470236

gianm reviewed Dec 18, 2024

View reviewed changes

cecemei added 2 commits December 18, 2024 14:03

Policy change

0664dfc

Added a Policy class to wrap the filter, updated some Javadoc

e7ebcf8

cecemei force-pushed the security2 branch from a470236 to b19728b Compare December 19, 2024 02:31

cecemei added 4 commits December 18, 2024 18:38

Merge branch 'master' into security2

cfe8e73

fix test

5199354

remove VIEW from restricted applicable resource types, add tests for …

390caac

…AuthorizationResult class, dart sql, msq sql, fix bug, added restricted data source to calcite test data

Merge branch 'master' into security2

6bdc39d

github-advanced-security bot found potential problems Dec 19, 2024

View reviewed changes

cecemei added 5 commits December 19, 2024 21:05

add Permission enum in AuthorizationResult class, add TablePolicySecu…

e81a25d

…rityLevel enum in Policy class, updated a bunch of tests

reverted changes in SegmentMetadataQuery, since now query from druid-…

ec6e3b5

…internal won't be restricted

revert change in test as well

f1aa791

clean up a bit

a1b3b06

updated the AuthorizationResult class a bit, along with some tests

17313d9

LakshSingla reviewed Jan 6, 2025

View reviewed changes

update on RestrictedSegment to implement SegmentReference directly.

2eaf63a

abhishekagarwal87 reviewed Jan 7, 2025

View reviewed changes

gianm reviewed Jan 7, 2025

View reviewed changes

clintropolis reviewed Jan 7, 2025

View reviewed changes

Update Policy inteface and added NoRestrictionPolicy and RowFilterPol…

6407479

…icy class. Updated AuthorizationResult class as well.

github-advanced-security bot found potential problems Jan 7, 2025

View reviewed changes

server/src/test/java/org/apache/druid/initialization/AuthorizationResultTest.java Fixed Show fixed Hide fixed

server/src/test/java/org/apache/druid/initialization/AuthorizationResultTest.java Fixed Show fixed Hide fixed

cecemei added 4 commits January 7, 2025 17:00

added back AuthResult class, and some javadoc

009e8db

minor update

cedf9bb

add visit(CursorBuilderSpec) to policy interface, and add tests for p…

e275b1f

…olicy subclasses

format

0d26d74

clintropolis reviewed Jan 8, 2025

View reviewed changes

cecemei added 3 commits January 9, 2025 09:55

Remove TablePolicySecurityLevel enum and add tests in QueryLifecycleT…

ab8eed1

…est for SegmentMetadataQuery.

Update QueryResource to check for basic access, native json query sho…

18c4828

…uld work with basic access.

rename isUserWithNoRestriction to allowAccessWithNoRestriction

3ba7d35

gianm reviewed Jan 9, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add row-level security filter in query #17564

Add row-level security filter in query #17564

cecemei commented Dec 13, 2024 •

edited

Loading

gianm left a comment

LakshSingla Jan 6, 2025

abhishekagarwal87 Jan 7, 2025

gianm Jan 7, 2025

cecemei Jan 7, 2025

clintropolis Jan 8, 2025

gianm Jan 9, 2025

gianm Jan 7, 2025

gianm Jan 7, 2025

clintropolis Jan 7, 2025

gianm Jan 7, 2025

gianm Jan 7, 2025

clintropolis Jan 7, 2025

clintropolis Jan 7, 2025

clintropolis left a comment

clintropolis Jan 8, 2025

gianm Jan 9, 2025 •

edited

Loading

clintropolis Jan 8, 2025

clintropolis Jan 8, 2025

gianm Jan 9, 2025

gianm Jan 9, 2025

gianm Jan 9, 2025

gianm Jan 9, 2025

gianm Jan 9, 2025

gianm Jan 9, 2025

gianm Jan 9, 2025

gianm Jan 9, 2025

gianm Jan 9, 2025

gianm Jan 9, 2025

gianm Jan 9, 2025

		if (!authResult.isUserWithNoRestriction()) {
		throw new ForbiddenException(authResult.getErrorMessage());

Add row-level security filter in query #17564

Are you sure you want to change the base?

Add row-level security filter in query #17564

Conversation

cecemei commented Dec 13, 2024 • edited Loading

Description

Key changed/added classes in this PR

Caveats

gianm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

clintropolis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gianm Jan 9, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cecemei commented Dec 13, 2024 •

edited

Loading

gianm Jan 9, 2025 •

edited

Loading