2017-09-27 1 views
0

Ich habe ein Kundenmodell, das das integrierte Benutzermodell erweitert. Aber die PUT-Anfrage an den Update-Kunden funktioniert überhaupt nicht, selbst nach dem Bereitstellen eines korrekten access_token.Loopback kann Benutzer/Kunde mit PUT-Anforderung nicht aktualisieren

Ich habe mich als Benutzer mit dem Anmeldeendpunkt angemeldet und das access_token bekommen. Die PUT-Anforderung des Kunden zu aktualisieren Attribute:

PUT http://localhost:3000/api/customers/59cb873ab21a902ab0afece1 

Wie pro meinem Verständnis der Besitzer in der Lage sein sollten, seinen eigenen Rekord zu aktualisieren, aber es hält wirft die folgenden Fehler:

{ 
    "error": { 
     "statusCode": 401, 
     "name": "Error", 
     "message": "Authorization Required" 
    } 
} 

Auch wenn Ich versuche zu löschen mit dem gleichen access_token es funktioniert gut.

DELETE http://localhost:3000/api/customers/59cb873ab21a902ab0afece1 

Die customer.json Datei sieht unten wie:

{ 
    "name": "customer", 
    "plural": "customers", 
    "base": "User", 
    "idInjection": true, 
    "options": { 
    "validateUpsert": true 
    }, 
    "properties": { 
    "realm": null, 
    "emailVerified": null, 
    "name": { 
     "type": "string" 
    }, 
    "username": { 
     "type": "string" 
    }, 
    "cellnumber": { 
     "type": "string" 
    }, 
    "status": { 
     "type": "string" 
    } 
    }, 
    "validations": [], 
    "relations": { 
    "accessTokens": { 
     "type": "hasMany", 
     "model": "accessToken", 
     "foreignKey": "userId" 
    } 
    }, 
    "acls": [ 
    ], 
    "methods": {}, 
    "replaceOnPUT": false 
} 

Wohin gehe ich falsch? Wie behebe ich dieses Problem?

Dank

Antwort

0

Sie versuchen, bereitstellende Benutzer können ACL wie folgendes Beispiel

"acls": [ 
    { 
     "accessType": "EXECUTE", 
     "principalType": "ROLE", 
     "principalId": "$authenticated", 
     "permission": "ALLOW" 
    }, { 
     "accessType": "*", 
     "principalType": "ROLE", 
     "principalId": "$everyone", 
     "permission": "DENY" 
    } 
    ] 

Hoffnung dies funktionieren wird.

+0

Nein, es funktioniert nicht.Was nützt es, weitere ACLs hinzuzufügen, wenn das Standardbenutzermodell bereits ein solches hat? Das Problem besteht darin, dass die Standard-ACL nicht funktioniert. –

0

Die Standard-ACL für das Benutzermodell erfordert eine Authentifizierung, auf alle Anfragen mit Ausnahme der POST-Anfrage - das ist also kein Problem.

Um GET-, PUT/PATCH- oder DELETE-Anfragen für dieses Modell zu stellen, müssen Sie sich anmelden und ein Token in Ihren Anfragen verwenden.

Beispiel in Ihrem Fall:

  • POST einen neuen Kunden wie: { "username": "stack_user", "email": "[email protected]", "password":"stackoverflow" }; unter POST http://localhost:3000/api/customers/
  • LOGIN mit E-Mail und Passwort: { "email": "[email protected]", "password":"stackoverflow" }; bei POST http://localhost:3000/api/customers/login

=> erhalten Sie eine Antwort wie erhalten:

{ 
    "id": "jazSRZYbjJai3JeCYpb6u4nYsRGWbaQk5SK3nQPkMoNeUdrAYK3kYwaXECrfj6Vk", 
    "ttl": 1209600, 
    "created": "2017-09-29T11:44:16.111Z", 
    "userId": "59cb873ab21a902ab0afece1" 
} 

wo id die access_token ist.

  • es bei PUT http://localhost:3000/api/customers/59cb873ab21a902ab0afece1?access_token=jazSRZYbjJai3JeCYpb6u4nYsRGWbaQk5SK3nQPkMoNeUdrAYK3kYwaXECrfj6Vk

verwenden und es sollte funktionieren.


Wenn nicht, können Sie versuchen, diese Zeile zu entfernen:

"replaceOnPUT": false 

und versuchen Sie es erneut?

+0

Hallo F3LIX79, ich folge dem gleichen, aber es funktioniert nicht. Das Entfernen von replaceOnPut hilft auch nicht. Es scheint ein Problem zu sein, wenn wir das Standardbenutzermodell erweitern. –

+0

Schaffst du es, dass es im Swagger-API-Explorer funktioniert, indem du das Zugriffstoken direkt über der Ecke deiner Browserseite einrichtest? – F3L1X79

+0

Nein. Es funktioniert nicht mit Zugriffstoken entweder in der API Swagger oder Postman. –