FilterExpressionCheck: How to filter all or none?

[Brutus5000]

Imagine the following use case:

I have a Datasource entity which has a relationship restrictions to entities of type Restriction. Restriction contains a tenantId.

My user object has

• a boolean flag globalAdmin
• a list of tenantIds he has access to
  (I'm fetching the user via my Spring Security Context - this is not a User Check as it will be compared to the rows)

Now I build a FilterExpressionCheck with this logic:

• If user is globalAdmin == true then return all entities
• Else
  • If user.tenantIds.isNotEmpty() then use FilterPredicate(somePath, Operator.IN, user.tenantIds)
  • Else return nothing

I am looking for a pre-defined FilterExpression for return all items and return nothing. Is there such a thing?

For now I'm using an ugly workaround by creating a FilterPredicate on the Datasource.id being null or not null, but that looks smelly and ugly and needs to be recreated for every entity I want to filter this way.

[aklish]

I would break this up into two checks:

• A user check ("Principal Is Global Admin")
• A filter expression check ("Principal Is Tenant")

The read permission rule would then be: "Principal Is Global Admin OR Principal Is Tenant"

If the user check passes (principal is admin), the filter expression will not be applied.

The filter expression check can be implemented to extract the list of tenantIds from the the user principal and then return a different expression depending on whether there are any tenants.

If there are no tenants, return a FalsePredicate. Otherwise, return FilterPredicate(somePath, Operator.IN, user.tenantIds)

[Brutus5000]

Yeah splitting these up that makes things a lot simpler.

However I do not really understand how the FalsePredicate works. Does it make a difference what path I select there? And isn't that basically what I was asking for?

[aklish]

False Predicate generates '(1 = 0)' in JPQL:

        operatorGenerators.put(FALSE, (predicate, aliasGenerator) -> {
            return "(1 = 0)";
        });

In memory, it executes:

    private static <T> Predicate<T> isFalse() {
        return (T entity) -> false;
    }

I don't think it matters what path is passed in the constructor. We probably ought to remove the argument altogether.

[Brutus5000]

Nice. So I guess TruePredicate then does the opposite. So this then is what I was looking for in my initial question :)

Follow up questions on FilterExpressions though: They get called a lot. Actually for almost every record that is in the database (the numbers don't exactly add up). Why? Wasn't the purpose of this to just pass it to JPQL and then be done with it? Am I doing something wrong?
The generated SQL itself looks perfectly fine and does the filtering as expected.

[aklish]

FilterExpressions are also operation checks, so they can be evaluated in memory at any time. Several scenarios where this happens:

1. A logical OR between a filter expression and an operation check. Both have to be evaluated in memory and nothing can be pushed to the datastore.
2. Elide prunes model fields from the payload response based on what the fields the client can see. These rules can include filter expression checks - and they get executed in memory. An individual field decision is different than the row level decision of what gets returned to Elide from the data store.
3. If you are doing an update or other operation on a field protected by a filter expression check - it will get executed in memory.

This reminds me that we need to update the docs with the security design. I think it will help explain how all these pieces interact (filters, in-memory checks, user checks, and the various CRUD operations).