Definitive answer to ACL for related models?

[charlie-s]

I'm unable to find a clear answer, apologies if I'm mis-reading issues or documentation.

Is there a built-in way to limit access to ModelB when it has a relationship to ModelA and the current user has read access to ModelA?

Related issues: #386, #960, #1362, #2953

The relevant documentation on this leads me to believe that the following model prevents the user from accessing the Order associated with a Job:

{
    "name": "Job",
    "relations": {
        "order": {
            "type": "belongsTo",
            "model": "Order",
            "foreignKey": ""
        }
    },
    "acls": [
        {
            "principalType": "ROLE",
            "principalId": "$everyone",
            "permission": "DENY",
            "property": "__get__order"
        }
    ]
}

In practice, this prevents the user from getting /Job/1/Order but does not prevent them from getting /Job/1?filter={include:"order"}.

Based on reading the other issues, it seems that the only way to actually limit access is to include the relevant ACL above, and to also include the disableInclude in the relation definition. This basically disables the relation completely (remote calls + node app), so what would be the point in defining a relation in the first place? (just looking for clarity)

If this is correct (esp as reported in #1362 (comment)) should the documentation still suggest "You can use these related model methods to control access to the related routes."?

I see from @bajtos answers from Oct 2018 that LB3 is in LTS only at this point, so just wanting to get a definitive answer on this so that I can plan around it. If my assumptions are correct here, perhaps the warnings/instructions on the doc page should be revised.

[bajtos]

Hi @charlie-s, thank you for opening this discussion. Based on my best knowledge, your assessment is correctly describing the current level of support for relations in LB3.

Based on reading the other issues, it seems that the only way to actually limit access is to include the relevant ACL above, and to also include the disableInclude in the relation definition. This basically disables the relation completely (remote calls + node app),

Maybe there is a workaround possible, where you keep "include" enabled for Node.js API and add a beforeRemote hook that will remove include fields from the filter argument provided by remote clients? The difficult part is to ensure your hook covers all execution paths and different places where include can be specified.

so what would be the point in defining a relation in the first place? (just looking for clarity)

As I understand history of LB, we were prioritizing broad set of REST APIs and features available out of the box to make it easy to quickly build prototypes. We did not fully anticipate that a REST API can be too broad once an app starts moving to production, and that we also need to give developers enough control about the shape of the REST API.

The behavior you are seeing is the result of this: relations are easy to use in full, but difficult to trim down.

The point I want to make is that this was not an intentional decision on our side, or at least I believe it was not intentional.

If my assumptions are correct here, perhaps the warnings/instructions on the doc page should be revised.

I like the idea to improve our documentation to make this issue clear to readers. Any suggestions on what exact changes to make? Can you perhaps contribute these documentation changes yourself? See https://loopback.io/doc/en/contrib/doc-contrib.html to get started.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.