-
I am currently using CASL in Cloudflare Workers, and I want to implement the process in a simpler way. Therefore, it should not have any relation to a database. This is how I'm doing it type Subject = InferSubjects<User & { __caslSubjectType__: 'User' }>
type AppAbility = PureAbility<[string, Subject]>
export const createAbility = (user: User | null) => {
const { can, cannot, build } = new AbilityBuilder<AppAbility>(PureAbility)
switch (user?.role) {
case Role.ROOT:
can('update', 'User', 'isVerified', { isVerified: false })
break
case Role.ADMIN:
can('update', 'User', 'isVerified', { isVerified: false })
break
case Role.COLLABORATOR:
break
case Role.AUDIENCE:
break
}
return build()
} This doesn't throw any typescript errors, but when I run the tests, CASL requires me to provide fieldMatcher and conditionsMatcher const { can, cannot, build } = new AbilityBuilder<AppAbility>(createMongoAbility) However, my question is: Does the "mongo" in createMongoAbility refer to MongoDB? If my approach doesn't require any database adaptation, should I still use createMongoAbility as a parameter? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
PureAbility is a base class which doesn’t support conditions if they are not passed as a factory function. You need to use |
Beta Was this translation helpful? Give feedback.
PureAbility is a base class which doesn’t support conditions if they are not passed as a factory function.
You need to use
createMongoAbility
. It’s called MongoAbility because it allows to define conditions using Mongo query language. Casl also supports custom implementation of conditions. For example, @casl/prisma provides PrismaAbility which allows to specify conditions using Pridma query language