Devo nascondere i campi nelle rappresentazioni di risorse REST in base al ruolo di sicurezza dell'utente?

Question

Devo nascondere i campi nelle rappresentazioni di risorse REST in base al ruolo di sicurezza dell'utente?

#1 da (4 voti)

7

Qual è la prassi migliore per esporre campi diversi per una risorsa in base al ruolo dell'utente / ai privilegi ACL nel sistema?

Diciamo che ho un endpoint, groups/{:group_id} . Le mie regole aziendali indicano quanto segue:

Gli utenti non autenticati possono vedere solo: name e ID campi
Gli utenti autenticati possono vedere: name , ID , managers e access_code campi
I gestori di gruppo possono vedere name , ID , managers , access_code e members .

Rispettivamente, i record possono apparire come:

/* Non-Authenticated User */
{
    "id": "abe80d",
    "name": "Foobar Group"
}

/* Authenticated User */
{
    "id": "abe80d",
    "name": "Foobar Group",
    "access_code": "abc123",
    "managers": {
        "_href": "http://example.org/people/bds983a",
        "_href": "http://example.org/people/cde03rf",
    }
}

/* Manager */
{
    "id": "abe80d",
    "name": "Foobar Group",
    "access_code": "abc123",
    "managers": {
        "_href": "http://example.org/people/bds983a",
        "_href": "http://example.org/people/cde03rf",
    },
    "members": {
        "_href": "http://example.org/people/bds983a",
        "_href": "http://example.org/people/cde03rf",
        "_href": "http://example.org/people/jvs239a",
        "_href": "http://example.org/people/nnd9323",
    }
}

Dovrebbe essere un singolo endpoint / URI che mostra diversi set di campi per diversi livelli di autenticazione, o dovrei in qualche modo suddividerli in tre diversi URI?

Sembra che URL diversi per la stessa risorsa non siano corretti, ma un client che non sa esattamente quali campi verranno recuperati è anche negativo? C'è una buona pratica in questa situazione?

rest web web-services

posta caseyamcl 20.11.2014 - 20:45

fonte

1 risposta

Leggi altre domande sui tag rest web web-services

Trovare la distanza media di Hamming più bassa quando l'ordine delle corde è importante Serializzare un oggetto in modi diversi

score 4 · Accepted Answer

Di solito un URI di una singola risorsa perché vuoi separare le preoccupazioni tra DOVE vive la risorsa e l'OMS lo accede.

Nel tuo caso, "CHI" accede alla risorsa è determinata in base a due parametri: l'utente è autenticato? In tal caso, qual è il livello di autorizzazione?

Per il livello di autorizzazione, è possibile implementarlo utilizzando i gruppi e aggiungere gruppi nel tempo oppure modificare il livello di autorizzazione di vari gruppi nel tempo. Questo non dovrebbe cambiare da dove i dati devono essere recuperati da un client.

Un esempio pratico è che quando un client (ad esempio un'app nativa su un dispositivo mobile) consuma la tua API, autenticherà l'utente e renderà la vista basata sui dati che riceve. Se (dal lato server), vengono aggiunti nuovi gruppi o viene modificato il livello di autorizzazione dell'utente, non dovrebbe avere alcun impatto sul codice client.

It seems like different URLs for the same resource is bad, but a client not knowing exactly what fields would be retrieved is also bad? Is there a best practice in this situation?

In genere ci si aspetta che i clienti gestiscano questi casi. Se hai avuto URI separati, hai ancora il problema che viene colpito un URI che richiede privilegi più elevati di quello che l'utente ha, nel qual caso la richiesta dovrà fallire. Ancora più importante, senza che sia stata eseguita l'autenticazione, come fa un cliente a sapere quale URL colpire?

D'altra parte, se il client era codificato per aspettarsi dati in base a vari livelli di autorizzazione, il codice sarebbe abbastanza generico da gestire casi futuri in cui i dati restituiti vengono modificati. Questo è importante perché in genere non si dovrebbe presumere che una risorsa rimanga costante e non si evolva nel tempo.

Ci sono fortunatamente molti strumenti e tecniche disponibili sia in XML che in JSON per gestire quantità arbitrarie di dati restituiti dal server purché il contratto dello schema non sia stato violato.

Nell'esempio, hai fornito, avrei codificato il mio client per avere lo schema per tutti e cinque i campi, ma mi aspetto che qualsiasi campo diverso da nome e ID sia nullo. Se non è nullo, renderlo all'utente, ma se lo è, non mostrarlo o fornire un messaggio appropriato. In futuro, se decidessi di consentire agli utenti autenticati di non vedere gli access_code o gli utenti non autenticati per vedere i gestori, il codice cliente non dovrebbe essere modificato.