Esistono best practice per esporre le autorizzazioni di risorsa/ACL a un front-end tramite un'API RESTful?

Question

La domanda praticamente lo copre. Data un'API RESTful in cui abbiamo più tipi di risorse e varie autorizzazioni utente in merito a chi può CRUD, esistono delle best practice consolidate per esporre tali autorizzazioni al front-end in modo che le autorizzazioni non debbano essere memorizzate in due punti?

Ho una pura applicazione JS e ho bisogno di sapere quando, per esempio, visualizzare modificare ed eliminare i collegamenti per una determinata risorsa. Vorrei un modo standard per prendere queste decisioni in base agli ACL archiviati nel back-end. Considerai forse di riportare una porzione di ACL nella busta REST per tutte le risposte GET, ma speravo forse che qualcuno conoscesse una best practice consolidata.

Per quello che vale, sto anche utilizzando Symfony2 e il suo componente di sicurezza.

Answer 1

In uno scenario puramente RESTful, il client non gestirà affatto un ACL. Piuttosto, poiché il cliente richiede informazioni, le risorse restituite includeranno i collegamenti da tali risorse a possibili collegamenti che il cliente potrebbe seguire. In questo modo il server sta dicendo al cliente cosa può e non può essere fatto con la risorsa data (specifica per chi lo sta richiedendo).

Esempio: il client JS recupera un payload JSON per un articolo che è stato acquistato ma non è ancora stato spedito. Il cliente potrebbe ricevere un carico utile che assomiglia a questo:

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

Poiché il server ha restituito il cancel-spedizione relazione di collegamento, significa che l'articolo dell'ordine è permesso di essere cancellata in questo momento. Ma immaginare che cosa la risorsa potrebbe essere simile dopo che è spedito e la richiesta viene fatta alcuni giorni dopo:

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

Il cancel-spedizione collegamento relazione non sarebbe più restituito dal server, perché non è più un'operazione consentita (cioè, non è possibile annullare un ordine dopo che è stato spedito).

Più controllo di accesso tradizionale può essere gestito allo stesso modo (vale a dire, non inviare il collegamento di annullamento della spedizione a un utente che non è autorizzato). Supponiamo che l'ordine non sia ancora stato spedito e che il tuo coniuge possa vedere che cosa hai ordinato ma non è autorizzato a cancellarlo. Avevano ottengono questo ritorno:

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

Quindi, in sintesi, i collegamenti restituiti in ogni risposta incapsulano e rappresentano ciò che il richiedente è autorizzato a fare in ogni momento nel sistema.

In ogni caso, è necessario verificare per l'autorizzazione appropriata sul server per la richiesta effettuata, in quanto non si sa mai quando qualcuno potrebbe hackerare con URL non elaborati.