Utilizzo dell'API Web nel sito Web con viste basate sui ruoli

The goal would be to not have the view in the website if the user is not authorized to preform such action. Not just do a trick and hide it the HTML (Tech-savey user can see html code for actions/data forms they shouldn't).

Sono d'accordo con te. Questo sarebbe il caso ideale anche per me. Tuttavia, ritengo che questo sia dettagli di implementazione . Non c'è niente di sbagliato nel nascondere il codice HTML, non appena l'API implementa l'autorizzazione e l'autenticazione.

Un tecnico non ha bisogno di esaminare il codice. Ad esempio, lui / lei può tenere traccia delle connessioni del browser e provare per ogni URI dell'API, diversi metodi HTTP. Fondamentalmente, lui / lei può ignorare il client e attaccare l'API da qualsiasi altra applicazione (arricciatura, Postman, client java, ecc ...)

how do you control the user view in the website consuming the API, based on the API permissions

Comunque, se l'API si attacca a REST, dovrebbe essere possibile per noi ottenere ciò che vogliamo. Quello di cui abbiamo bisogno prima è sapere quali azioni possiamo svolgere. Questo dovrebbe essere possibile con il metodo OPTIONS . ¹

Autorizzato

OPTIONS /rest/api/product HTTP/1.1
Host: example.net
Authentication: ...

HTTP/1.1 200 OK 
Allow: HEAD,GET,DELETE,OPTIONS

non autorizzato

OPTIONS /rest/api/product HTTP/1.1
Host: example.net    

HTTP/1.1 401 Unauthorized

È più facile a dirsi che a farsi. Potrebbe comportare molte più chiamate all'API di quelle inizialmente previste.

Un modo per risolvere il problema precedente con OPTIONS potrebbe essere l'implementazione di HATEOAS. In altre parole, potremmo rendere l'API più descrittiva.

Implementando HATEOAS la risposta API non fornisce solo rappresentazioni di risorse. Fornisce inoltre collegamenti a più risorse. I collegamenti possono essere tanto descrittivi quanto lo riteniamo appropriato. Ad esempio, guarda il modello di API PayPal .

La vista popolerebbe i suoi controlli in base ai collegamenti. Nessun collegamento, nessun controllo (pulsante, modulo, ecc.)

Per quanto riguarda le tue idee, anch'io ho accettato. Non mischiare API e visualizzazioni. Ogni cliente ha le proprie preoccupazioni e queste preoccupazioni -IMO- dovrebbero essere affrontate in modo indipendente. Più agnostico è l'API per questi problemi, meglio è.

As well as no way of knowing via the website HTML/JS to see where the delte option is/how it works (Of course the delete view shows to users with that permission set)

Supporrò che abbiamo già risolto il problema con il blocco HTML. Secondo le tue congetture, l'utente potrebbe comunque guardare il codice JS. Sì, e possiamo anche offuscare il codice.

D'altro canto, se non vogliamo che gli utenti costruiscano i propri clienti, possiamo (dovremmo) fornirgliene uno. Ad esempio, come fa Google.

^{1: In base ai metodi Consentiti , decidiamo cosa fare. Ricorda che Javascript può nascondere elementi DOM modificando gli stili, ma può anche aggiungere / rimuovere elementi in modo dinamico.}

Perché ti interessa se l'HTML / JS ha la funzionalità di eliminazione nascosta? Posso dire che supponendo che tu abbia un'API in stile REST, qualsiasi persona che guarderà il tuo pulsante nascosto e capirà il perché / come / quando diventerà visibile sarà solo in grado di indovinare che il metodo DELETE HTTP contro la risorsa sarà essere il modo di cancellare la cosa Voglio capire il modello di minaccia che hai dove pensi che nascondere il pulsante e controllare i perms lato server non siano abbastanza buoni. Quindi la mia risposta sarebbe: no. La complessità extra non ne vale la pena.