MongoAbility is "turned back"(?) to a PureAbility ?/Refuses to take conditions as 3rd argument

[erkanImperiatec]

Hello there,

First of all, great work on casl, it is an amazing system, wanted to use it for a while but never got the chance.

I don't know if I am asking in the right place, sorry in advance.

I am having trouble using the ability created through either AbilityBuilder or createMongoAbility regarding their mongodb queries:
I tried both with createMongoAbility first and then swithced to AbilityBuilder using createMongoAbility but same result...

/ ---Other imports ---
import { AbilityProviderValuesType, PermissionObject } from "src/context/types";
import { AbilityBuilder, MongoAbility, createMongoAbility, buildMongoQueryMatcher } from '@casl/ability';
import {$eq, eq} from "@ucast/mongo2js";
import { Actions, Subjects, defaultPermissions } from "src/configs/ability";



// Define CASL Ability with typed actions and subjects
export type AppAbility = MongoAbility<[Actions, Subjects]>;
export type AppAbility = MongoAbility<[Actions, Subjects]>;



// Ability builder function that parses the permissions object and builds the corresponding CASL ability
export function defineAbilityFrom(permissionObject: PermissionObject | null): AppAbility {
  const { can, cannot, build } = new AbilityBuilder<AppAbility>(createMongoAbility);
  const conditionsMatcher = buildMongoQueryMatcher({$eq}, {eq})
  if (!permissionObject || Object(permissionObject).length === 0) {
    can(defaultPermissions.action, defaultPermissions.subject)
    return build()
  }

  permissionObject.Statement.forEach(statement => {
    const { Action, Effect, Resource } = statement;

    if (Effect === 'Allow') {
      Resource.forEach(resource => {
        const [subject, id] = resource.split(':'); // Split resource into subject and ID

        Action.forEach(action => {
          if (id === '*') {
            can(action as Actions, subject as Subjects); // Apply to all instances of the subject
          } else {
            can(action as Actions, subject as Subjects, { id: {$eq: Number(id)} });// --> this says that 3rd arg should be a string as if it is a PureAbility
          }
        });
      });
    }
  });

  // Then, apply the "Deny" statements to override any allow permissions
  permissionObject.Statement.forEach(statement => {
    const { Action, Effect, Resource } = statement;

    if (Effect === 'Deny') {
      Resource.forEach(resource => {
        const [subject, id] = resource.split(':');

        Action.forEach(action => {
          if (id === '*') {
            cannot(action as Actions, subject as Subjects);
          } else {
            cannot(action as Actions, subject as Subjects, { id: {$eq: Number(id)} });// --> this says that 3rd arg should be a string as if it is a PureAbility
          }
        });
      });
    }
  });
  const builtAbility = build({conditionsMatcher});
  console.log('builtAbility', builtAbility) // --> This shows it as a PureAbility
  return builtAbility; // Return the built ability
}

When i use ability with 2 arguments, meaning that i only check action and subject without a condition, the ability works fine when i call it in my components through a custom Hook.

However, when i try to use a condition(where there is an else for the if (id==="*") js conditions), firstly, the intellisense inside the defineAbilityFrom function tells me that it expects a string rather than an object, even though it lets me declare it without throwing an error.

But when i try to use it with a 3rd argument in my components to do the actual checking like so( I am not using Can components from @casl/react yet i was trying to see if my abilities worked first, I have@casl/reactV4.0.0 installed, waiting to be implemented after i fix the current problem ):

ability && ability.can("product.unarchive", "product", {id: item.product.id}) && <UnarchiveButton />

I have the following error thrown in my React component that says:

Error: The 3rd, `field` parameter is expected to be a string. See https://stalniy.github.io/casl/en/api/casl-ability#can-of-pure-ability for details

The link redirects to v5, even though i am using 6.7.1, which leads to the following section:

can of PureAbility

Checks that the provided action and subject satisfy permissions. Depending on Abilities generic parameter this function accepts either single action argument (when Abilities is a string) or 3 arguments (when Abilities is a tuple).

• Parameters
• • action: string - an action to check
• • subject: Subject - a subject to check
• • field?: string - a field to check

I even tried to use the buildConditionMatcher in case i had to explicitly declare the query operators i needed, but to no avail.

With a few console logs of the built abilites their signature is always PureAbility even though I solely createMongoAbility and MongoAbilty so I don't understand why it fallsback to PureAbility's signature when trying to use the 3rd argument of can/cannot

Am i doing something wrong ? I might have skiped an important part on the docs but can't seem to find it.

[erkanImperiatec]

Any thoughts on this ?

[stalniy]

Hi,

you are in trap of common misconception.

Builder method accepts conditions but ability check method accepts action and entity. Based on entity type (this is called subject type in casl), ability understands what to permissions to use.

createMongoAbility creates an instance of PureAbility with preconfigured options. So it’s the same result as using new Ability(). I want to get rid of this distinction between PureAbility and Ability to reduce amount of code. Ability just inherits PureAbility and passes inside options to its constructor. This can be done inside simple function.

The plan is to rename PureAbility to Ability and use functions to preconfigure Ability

[erkanImperiatec]

Hello first of all thanks for your reply,

So if understand correctly, when the abilty is built by ability builder, i should do ability.can(action, product) and it will go check for the condition i defined in the builder inside of the entity ?

[stalniy]

Yes, make sure that CASL can detect type of your entities. If your entities are POJO then you have 2 options either enhance its type after fetching from API on service layer (adding additional hidden property) or by using subject helper.

I guess it should be explained in the guide

[erkanImperiatec]

Okay thanks for your suggestions, I had not understood that abilities do not need conditions, etc... after they have been built. I have managed to make it work, although my POJOs are not extensible for some reason , might be transformed in react-redux as i am using it to retrieve my items from store state with useSelector and render these in my components. I have found a way arround it by doing :
ability && ability.can("product.unarchive", subject('product', **{...** item.product **}**) && <UnarchiveButton />
It feels a bit hacky but seems like a solution between 1 and 2 listed in this section of the docs:

So, now you have 2 options:

1. Use subject helper everywhere you use ability.can as shown in the example above.
2. Set subject type for all DTOs after retrieving them from server