Loopback-Komponenten-Speicher acl 401 Fehler

Question

Der Behälter Modell sieht wie folgt aus:

{ 
    "name": "container", 
    "base": "Model", 
    ... 
    "acls": [ 
    { 
     "principalType": "ROLE", 
     "principalId": "$everyone", 
     "permission": "DENY", 
     "accessType": "*" 
    }, 
    { 
     "principalType": "ROLE", 
     "principalId": "admin", 
     "permission": "ALLOW", 
     "accessType": "WRITE" 
    } 
    ] 
} 

Wenn ich ein Bild, um es per Post gibt einen 401-Fehler. Ich bin sicher, dass ich als 'admin' Benutzer angemeldet bin, weil ich zwei Anfragen mit dem gleichen Zugriffs-Token und der gleichen acl im JSON-Modell mache. Für den ersten (nicht Container) funktioniert es, aber für die Container nicht.

Gibt es ein Problem mit der Container-ACL?

----- ----- Bearbeiten

Beginnend mit DEBUG = Loopback: Sicherheit: acl es zurück:

---ACL--- 
model container 
property * 
principalType ROLE 
principalId $everyone 
accessType * 
permission DENY 
with score: 7495 
---ACL--- 
model container 
property * 
principalType ROLE 
principalId admin 
accessType WRITE 
permission ALLOW 
with score: -1 

"property": "*" Standard in acl ist.

Für die erste Anfrage (nicht Container) gibt es das gleiche zurück, aber admin-write-allow hat einen höheren Score als $ everyone - * - deny.

Einstellung "score": -2 funktioniert nicht.

Answer 1

Sie definieren keine Eigenschaft (grundsätzlich eine Methode), also denke ich, dass die AC1-Auflösung Ihrem ersten und zweiten Gewicht mehr Gewicht verleiht.

"acls": [ 
{ 
    "principalType": "ROLE", 
    "principalId": "$everyone", 
    "permission": "DENY", 
    "accessType": "*" 
}, 
{ 
    "principalType": "ROLE", 
    "principalId": "admin", 
    "property": "*", // Add this line 
    "permission": "ALLOW", 
    "accessType": "WRITE" 
} 
] 

Aber dann kann ACL manchmal schwierig sein, herauszufinden. Ich würde empfehlen, debug string mit genau zu sehen, was dem ACL-System aufgelöst hat:

an Fenstern:

set DEBUG=loopback:security:acl && node . 

EDIT:

Die Frage war eigentlich von der Zugriffsart kommen (angeforderten Endpunkt war EXECUTE anstelle von WRITE), daher ACL nicht wie erwartet gelöst.