Gibt es Best Practices zum Offenlegen von Ressourcenberechtigungen/ACL für ein Frontend über eine RESTful-API?

Question

Die Frage deckt so ziemlich alles ab. Bei einer RESTful-API, bei der wir mehrere Ressourcentypen und verschiedene Benutzerberechtigungen für die CRUD-Berechtigung haben, gibt es Best Practices, um diese Berechtigungen dem Frontend zur Verfügung zu stellen, damit die Berechtigungen nicht an zwei Orten gespeichert werden müssen?

Ich habe eine reine JS-Anwendung und ich muss wissen, wann zum Beispiel Links für eine bestimmte Ressource bearbeiten und löschen. Ich möchte eine Standardmethode, um diese Entscheidungen direkt basierend auf den ACLs zu treffen, die im Backend gespeichert sind. Ich überlegte, ob ich vielleicht einen ACL-Teil für alle GET-Antworten in den REST-Umschlag zurückbringen könnte, aber ich hoffte, dass jemand von einer etablierten Best Practice wusste.

Für was es wert ist, verwende ich auch Symfony2 und seine Sicherheitskomponente.

Answer 1

In einem reinen RESTful-Szenario würde der Client überhaupt keine ACL verwalten. Wenn der Client Informationen anfordert, enthalten zurückgegebene Ressourcen Links von diesen Ressourcen zu möglichen Links, denen der Client folgen könnte. Auf diese Weise teilt der Server dem Client mit, was mit der gegebenen Ressource gemacht werden kann und was nicht (spezifisch für wer es anfordert).

Beispiel: Ihr JS-Client ruft eine JSON-Nutzlast für einen Artikel ab, der gekauft, aber noch nicht ausgeliefert wurde. Der Client kann eine Nutzlast erhalten, die wie folgt aussieht:

{ 
    "name": "Gadget 1", 
    "price": "16.99", 
    "status": "ORDERED", 
    "_links": { 
    "details": { "href": "/item/a631723d69/details", 
       "method": "GET"), 
    "cancel-shipment": { "href": "/item/a631723d69", 
       "method": "DELETE" } 
    } 
} 

Da der Server die Abbrechen-Sendung Link Beziehung zurück, bedeutet dies, dass das Element in der Reihenfolge im gegenwärtigen Augenblick abgebrochen werden darf. Aber vorstellen, was die Ressource aussehen könnte, nachdem es versendet und die Anfrage wird einige Tage später gemacht:

{ 
    "name": "Gadget 1", 
    "price": "16.99", 
    "status": "SHIPPED", 
    "_links": { 
    "details": { "href": "/item/a631723d69/details", 
       "method": "GET") 
    } 
} 

Die cancel-Sendung Link Beziehung würde nicht mehr vom Server zurückgegeben werden, weil es nicht mehr zulässig Betrieb (dh Sie können eine Bestellung nicht stornieren, nachdem sie versandt wurde.

Die traditionellere Zugangskontrolle kann auf die gleiche Art und Weise verwaltet werden (d. H., Senden Sie den Link zum Stornieren einer Sendung nicht an einen Benutzer, der nicht autorisiert ist). Angenommen, die Bestellung wurde noch nicht versendet und Ihr Ehepartner kann sehen, was Sie bestellt haben, aber nicht stornieren. Sie würden diese zurück:

{ 
    "name": "Gadget 1", 
    "price": "16.99", 
    "status": "ORDERED", 
    "_links": { 
    "details": { "href": "/item/a631723d69/details", 
       "method": "GET") 
    } 
} 

Also zusammenfassend, die Verbindungen in jeder Antwort zurückgegeben kapseln und darstellen, was der Anforderer berechtigt ist, zu einem bestimmten Zeitpunkt in dem System zu tun.

In jedem Fall müssen Sie müssen überprüfen für die entsprechende Autorisierung auf dem Server für die Anforderung vorgenommen wird, wie Sie nie wissen, wenn jemand mit rohen URLs hacken kann.