Create pages from question issues and gitter questions

[stalniy]

Tasks:

• [x] 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)

• example, article, guideline (https://blog.feathersjs.com/access-control-strategies-with-feathersjs-72452268739d)

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)

const vehicleIds = await getVehicleIds(user)

can(['read', 'update'], 'document', { vehicle: { $in: vehicleIds } })

2. Denormalize your scheme. For example, add additional user_id field to vehicle document
3. Think whether you can embed document as subdocument to vechicle, something like this:

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

4. Just don't define rule per documents and enforce them in routes (REST or GraphQL doesn't matter).

// 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

• how/when to set ability rules (Vue, React, Angular). Dont update this.$ability! (#210)
• restore rules on page refresh
• how to check without subject name (#101)
• permissions on router (https://medium.com/@sergiy.stotskiy/so-there-are-several-approaches-3ee962fb9fb5) (#233)
• integration with nuxtjs (#238)
• casl + react + redux (#148, #141, #165, #176, #189 )
• casl + firebase

Mongoose:

• accessibleFields(ability), why cannot use .select(..) to filter out disallowed fields (https://github.com/stalniy/casl-mongoose-example)
• casl and aggregation pipeline (#91)

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

[stalniy]

Need to check what is in this course https://codecourse.com/watch/vue-roles-and-permissions?part=using-casl-with-vue

[stalniy]

FAQ will be represented as a cookbook in the new docs

[stalniy]

empty conditions object behavior:

{
    "subject": "Financial",
    "action": "read",
    "fields": [
        "salary",
        "taxcode"
    ], 
   conditions: {}
},
{
    "subject": "Financial",
    "action": "read",
    "inverted": true,
    "fields": [
        “salary"
    ],
   conditions: {}
}

Conditions are sometimes populated but in this case they are not. After retrieving from the array of Abilities from the database I pass them in to Ability. When empty conditions objects are there the can/cannot don’t work as expected. If I remove empty conditions objects before pushing them into Ability they work exactly as expected. This is using the latest version of CASL. Cleaning up my data solves the problem so I’m happy but I thought you might like to know in case that is unexpected behaviour.