API REST e diritti utente

Question

API REST e diritti utente

#1 da (0 voti)

1

Sto sviluppando un'applicazione utilizzando l'API Angular e REST e sto affrontando un problema relativo al diritto di accesso dell'utente.

L'applicazione funziona in questo modo:

Una registrazione utente
Lo stesso utente crea la sua organizzazione
Invita le persone ad aderire all'organizzazione
Tutti gli utenti dell'organizzazione sono in grado di gestire molte cose diverse, come attività, agenda, ecc ...

Questo flusso può apparire molte, molte, molte volte.

Domanda 1

Per quanto riguarda i diritti globali, intendo qui, il fatto che un utente di un'organizzazione non può accedere al compito di un'organizzazione B ecc ...

Esiste un modello per evitare che, in ciascuno dei miei metodi API, controlli l'ID dell'organizzazione, il che significa che a volte devo lavorare su più altri oggetti e tabelle o raccolte, implicando molte richieste di database (e altro con lezioni riflessive)?

Domanda 2

Riguardo ai ruoli, dovrei testare il ruolo ogni volta che un utente invia una richiesta (nel senso che devo richiedere la tabella dei ruoli e controllare se può accedere a questo endpoint dell'API)? Oppure esiste un altro modello anche lì?

api rest access-control

posta Thomas thomas 07.10.2015 - 13:07

fonte

1 risposta

Leggi altre domande sui tag api rest access-control

Come evitare LazyInitializationException utilizzando Hibernate e Jersey Le strutture che generano HTML per te sono considerate dannose? [chiuso]

score 0 · Accepted Answer

No, in fondo non puoi evitarlo. L'unico modo potrebbe essere quello di avere un database indipendente per ogni organizzazione, altrimenti ogni singola richiesta effettuata dovrebbe includere l'ID dell'organizzazione per assicurarsi che gli utenti ricevano solo i dati che possono vedere o modificare.

Questo anche se una richiesta include direttamente un ID risorsa specifico. Di 'che hai un ordine di risorse. Ora hai un utente loggato che ha piena autorizzazione a vedere e modificare gli ordini della sua organizzazione. Nel primo passo recupera un modulo d'ordine con l'id 123. Modifica l'ordine e pubblica il risultato. Hai un URL RESTful come /order/123 per la richiesta POST.

Ora nel tuo controller potresti essere tentato di caricare questo ordine. Supponi che il tuo framework inserisca l'ID dall'URL in una variabile orders_id . Basta caricare l'ordine con SQL come questo (molto semplificato):

SELECT * FROM orders where id = 123;

Ma cosa succede se l'utente cambia l'ID e lo invia all'URL /order/456 ? Senza controllare l'utente e l'organizzazione, questa richiesta POST passerebbe semplicemente. Quindi, come minimo, dovresti prima caricare l'utente e poi ottenere l'organizzazione e SQL (ancora semplificato) dovrebbe fare qualcosa del genere:

SELECT * FROM orders where id = 123 AND organization_id = 456;

Quindi, anche se una singola risorsa potrebbe essere identificata dal suo ID, non puoi fare affidamento su questo. Lo stesso per tutto il resto che chiedi.

Simile ai ruoli, mentre sarebbe possibile includere role come attributo all'URL o payload che non sarebbe sicuro.

Anche se disponi di database diversi, devi caricare i dati dell'utente e assicurarti che venga utilizzato il database corretto. Altrimenti si verificano problemi simili.

Ovviamente l'ID utente dovrebbe essere archiviato crittografato nei dati della sessione in modo che un utente non possa cambiarlo come altri dati e agire come un utente diverso.