REST, memorizzazione nella cache e autorizzazione con più ruoli utente

Question

Abbiamo un sistema multi-tenant con diversi livelli di accesso, a volte anche per lo stesso utente che passa da più ruoli. Stiamo iniziando una discussione sul passaggio a un'implementazione RESTful delle cose. Sto solo iniziando a bagnarmi i piedi con l'intera cosa REST.

Quindi, come faccio a limitare l'accesso ai record corretti quando accedono a una risorsa, in particolare quando si prende in considerazione la memorizzazione nella cache? Se l'utente A accede a example.com/employees, riceverà una risposta diversa dall'utente B; l'utente A può persino ricevere una risposta diversa mentre passa a un ruolo diverso. Per facilitare il caching, l'id del ruolo dovrebbe essere in qualche modo incorporata nell'uri? Forse qualcosa come example.com/employees/123 (che viola le regole di REST), o come una sorta di risorsa subordinata come (che sembra sciocco, dal momento che role/### sarà aggiunto agli URI in tutto il luogo). Posso aiutare ma penso che mi manchi qualcosa qui.

modificati parlare di multi-tenancy

Answer 1

Avere le credenziali dell'utente agiscono come un fuori di identificatore di risorsa di banda (es. Presentando diversi punti di vista sullo stesso URL a ruoli diversi) si accende brutto lungo la strada. Utenti e applicazioni si scambiano gli URL tra di loro, le cose diventano aspre quando ciò accade e l'URL restituisce semplicemente contenuti diversi per credenziali diverse.

direi che ogni ruolo ha una visione diversa del mondo, perciò ogni ruolo deve accedere ad un percorso diverso per il servizio:

• amministratori si connettono a example.com/admin/employees
• utenti connettersi a example.com/users/employees
• ruolo foo probabilmente si collega al example.com/foo/employees

questo modo di separare il 'questo ruolo vede il mondo come tale e come' il par t dalla parte 'questa visione del mondo è accessibile al ruolo'. Un amministratore può collegarsi a example.com/users/employees e verificare come un utente ordinario vede il mondo, senza che l'amministratore debba impersonare prima un alias privilegiato più basso.

È inoltre possibile utilizzare la parte DNS per lo stesso scopo: admin.example.com/employees vs. users.example.com/employees. Questo è particolarmente fattibile per uno scenario correlato, quando il 'ruolo' non è un ruolo di sicurezza ma uno spazio dei nomi multi-tenant (cioè ogni account fornito dal servizio ottiene la propria 'vista' del servizio).