HasMany point d'entrée de relation non autorisé sur Loopback

Question

Nouveau sur Loopback, j'ai essayé de créer une API simple avec un modèle utilisateur et un modèle todo.

Le modèle utilisateur, nommé Todoer, est basé sur le modèle utilisateur intégré. créer un todoer, login, déconnexion, etc fonctionne comme un charme. Le modèle Todo est basé sur PersistedModel sans ACL pour le moment.

J'ai fait une Appartient Pour relation de modèle Todo à Todoer modèle d'avoir une propriété. J'ai fait aussi un hasMany relation de Todoer à Todo pour être en mesure de récupérer tous les todos d'un utilisateur par l'intermédiaire du point final GET/Todoer/{id}/todos

Avec un todoer connecté Avec le bon jeton et l'id, je peux facilement avoir des réponses de points de terminaison Todoer réservés aux utilisateurs connectés, comme par exemple GET /Todoer/{id}, donc je suis sûr que le mécanisme d'authentification fonctionne bien.

Mais chaque fois que je veux frapper GET /Todoer/{id}/todos, j'obtiens seulement un message d'erreur indiquant que je ne suis pas autorisé. Je suis toujours sûr d'avoir donné le bon jeton et l'identifiant Todoer obtenu lors de la connexion.

Même si je fais un grand ACL disant OK à tout à tous sur le modèle Todoer, il arrive la même chose.

Qu'est-ce que j'ai manqué? Je ne peux pas le comprendre ...

Merci pour votre aide ...

Answer 1

Vous devez prendre en compte ACLs d'un modèle intégré User. Vous êtes en train de courir dans sa règle générale DENY ACL. Il est prioritaire par rapport à votre règle ACL générale ALLOW (docs sur Priorité aux règles ACL).

Vous pouvez écrire une règle ACL plus spécifique pour l'obtenir (docs sur Accès aux modèles associés).

{ 
    "accessType": "*", 
    "principalType": "ROLE", 
    "principalId": "$everyone", 
    "permission": "ALLOW", 
    "property": "__get__todos" 
} 

Une autre option, qui pourrait être dans ce cas plus commode et sûr, est d'utiliser un rôle $owner dynamique sur lui-même Todo (docs sur rôles dynamiques).

{ 
    "accessType": "*", 
    "principalType": "ROLE", 
    "principalId": "$owner", 
    "permission": "ALLOW" 
} 

Si vous voulez comprendre ce qui se passe au sujet de ACLs dans votre application, il est très utile pour définir une variable d'environnement DEBUG-loopback:security:* pour activer la journalisation de sécurité assez vaste.