New to Loopback, I tried to make a simple API with a user model and a todo model.
The user model, named Todoer,is based on the built-in User model. create a todoer, login, logout, etc. works like a charm. The Todo model is based on PersistedModel with no special ACLs on it for the moment.
I made a Belongs To relation from Todo model to Todoer model to have an ownership. I made also a HasMany relation from Todoer to Todo to be able to retrieve all the todos of a user through the endpoint GET /Todoer/{id}/todos
With a todoer logged in, with the good token and id, I can easily have responses from Todoer endpoints reserved for logged users, like GET /Todoer/{id} for example, so I'm sure the authentication mechanism is working well.
But each time I want to hit GET /Todoer/{id}/todos, I only obtain a error message telling I'm not authorized. I'm always sure I gave the good token and Todoer Id obtained at login.
Even if I make a big ACL telling OK to everything to all on the Todoer model, it happens the same.
What did I miss ? I can't figure it out...
Thank you for your help...
You need to take into account ACLs of a built-in Usermodel. You are actually running into its general DENY ACL rule. It takes priority over your general ALLOW ACL rule (docs on ACL rule precedence).
You can write more specific ACL rule to get pass it (docs on Accessing related models).
{
"accessType": "*",
"principalType": "ROLE",
"principalId": "$everyone",
"permission": "ALLOW",
"property": "__get__todos"
}
Another option, which might be in this case more convenient and safe, is to use a dynamic $owner role on Todo itself (docs on Dynamic roles).
{
"accessType": "*",
"principalType": "ROLE",
"principalId": "$owner",
"permission": "ALLOW"
}
If you want to understand what is happening regarding to ACLs in your application, it's very useful to set a DEBUG environment variable to loopback:security:* to enable quite extensive security logging.