Search code examples
javascriptnode.jsaclloopbackjsstrongloop

StrongLoop: ACL for Subtable


I have two tables A and B. A hasOne B, B belongsTo A.

Now I have the following ACL in B:

{
  "principalType": "ROLE",
  "principalId": "$everyone",
  "permission": "DENY",
  "accessType": "*"
}

When I make a request to localhost/api/B/{id} I receive 401.

When I make a request to localhost/api/A/{id}/B I receive the data.

How can I fix this? Both should get a 401 error. Is there a solution where I don't have to touch A.json?

I could make an acl fix in A but I think, this would be ugly.

Found something in the StrongLoop Doc this means I have to define ACLs in A too?


Solution

  • In the current version of loopback that is the case. You can find different references in github issues https://github.com/strongloop/loopback/issues/960 https://github.com/strongloop/loopback-example-access-control/issues/41

    The document you linked actually has an explicit warning for the opposite problem, getting related instances when connected through User.

    If a model has a DENY ALL permission (for example a built-in model such as the User model), but related models have no ACLs, the related models will still not be accessible through the User model. So, for example, even if the books model's default ACL is ALLOW $authenticated for GET /books, the route GET /user/{id}/books default will still be DENY ALL.

    It seems you also need to be explicit in granting or not access, doing so for each generated method you wish to modify. An example for user having a hasAndBelongsToMany:

    {
      "accessType": "READ",
      "principalType": "ROLE",
      "principalId": "$authenticated",
      "permission": "ALLOW",
      "property": "__get__skills"
    },
    {
      "accessType": "WRITE",
      "principalType": "ROLE",
      "principalId": "$owner",
      "permission": "ALLOW",
      "property": "__link__skills"
    },
    {
      "accessType": "WRITE",
      "principalType": "ROLE",
      "principalId": "$owner",
      "permission": "ALLOW",
      "property": "__unlink__skills"
    }
    

    I remember seeing that a new way of handling ACL affecting related models would be implemented in version 3 but I can't find the reference again.