#204·casl

Create pages from question issues and gitter questions

Author: stalniyCreated Jun 26, 2019Updated May 18, 2021
Labelsmaintenance

Tasks:

  • go through all chat messages & questions and group questions
  • cookbook: share permissions between UI and API (the main question is it secure to transfer permissions on frontend?, #197, #227)
  • advanced: ability merging/inheritance (#110, #42, #43)
  • cookbook: different server and client model structure (#220)
  • cookbook: permissions on router
  • cookbook: common domain integrations
  • cookbook: CASL, DDD and specification pattern
  • cookbook: lazy ability https://github.com/stalniy/casl/issues/160#issuecomment-546994250
  • cookbook: permission for all records #259
  • Cookbook: AWS cognito

Basics:

  • simple abilities (without subjects)
  • any action, any subject (#201)
  • what are actions and subjects, where I can get these names, what they are
  • is it secure to transfer permissions on frontend?
  • ability inheritance/merging (#110)
  • whats the best way to check abilities if there is no model instance yet
  • merging abilities (#42, #43)
  • why there is no (#237)
    • ability.can(['read', 'update'], 'Post')
    • ability.can('read', 'Post', { userId: 5 })
  • minified version of app (model name) (#219)
  • CSP build
  • aliases as solution to check permission on multiple actions (#217)
  • mongodb conditions in details
  • subject name, implementation details of custom subject name (#6 , #177, #200, #214, #224)
  • make it clear in the docs what the pros and cons are of checking by subject type and by passing object
  • rules order (#123, #252)
  • fields vs conditions (#229, #236)
  • Check for "all" entities instead of "at least one" (#259)

Advanced:

  • custom operators
  • custom conditions matcher
  • custom field matcher
  • different server and client model structure (#220)

Security:

  • is it safe to share permissions? (#197). When you define all of the policies and use the abilities on the client side, its exposing all of the policies to public. Doesn't that pose any security issues?

Persisted permissions (i.e., roles)

Use cases:

  • 1 iphoneX, only particular users can manage it. others cannot

Hi, I'm trying to use your example (with mongoose) for my use case:

Domain definition: A "User" could has more "Vehicles" A "Document" must have a "Vehicle"

Schema definition:

vehicle { users: [ {type: objectId, ref: 'user'} ] }
document { vehicle: {type: objectId, ref: 'vehicle' }}

Rule definition I successfully defined an ability for user to read/update only his vehicles can(['read', 'update'], 'vehicle', { users: { $in: [user._id] } } )

How can I define a rule to check "user can read/update only documents of his vehicles" ? I tried with:

can(['read', 'update'], 'document', { "vehicle.users": { $in: [user._id] } } )

Obviously with no success.

casl don't manage references on related documents. You need to do it yourself.

So, I see few ways:

  1. Retrieve ids of all vehicles when you define rules. This works good in case if amount of vehicles not big (<= 1000)
javascript
const vehicleIds = await getVehicleIds(user)

can(['read', 'update'], 'document', { vehicle: { $in: vehicleIds } })
  1. Denormalize your scheme. For example, add additional user_id field to vehicle document
  2. Think whether you can embed document as subdocument to vechicle, something like this:
javascript
vehicle {
  documents: [Document],
  users: [ {type: objectId, ref: 'user'} ]
}
  1. Just don't define rule per documents and enforce them in routes (REST or GraphQL doesn't matter).
javascript
// app - express app

app.get('/vehicle/:id/documents', async (req, res) => {
   const vehicle = await Vehicle.findById(req.params.id)

   req.ability.throwUnlessCan('read', vehicle)
   const documents = Document.find({ vehicle: vehicle.id })

   res.send({ documents })
})
  • user has multiple roles
  • e.g a user can update an item created by another user in the same group. (#199)
  • share permissions with UI (#227)

frontend

Mongoose:

Tests

  • #138 how to test abilities?
  • test components wrapped by CASL (#216)

backend

  • filter out fields from resource returned by API, permitted/accessible fields
  • So the question is how to express something like: can('manage', 'Comment', { ??? <how to walk the object graph here> ???})
  • If I define conidtions for an ability, is it possible to check if a id is in a array of the object to be checked? Something like: can('edit' , 'Post', { moderators: "contain user.id" })
  • example with auth0
  • is it possible to add additional rules after the ability object was instantiated?
  • casl + feathers
  • casl + sql