Il modo migliore per fare l'autorizzazione lato client per un'applicazione JavaScript a pagina singola?

Question

Il modo migliore per fare l'autorizzazione lato client per un'applicazione JavaScript a pagina singola?

#1 da (5 voti)
#2 da (3 voti)
#3 da (1 voti)
#4 da (0 voti)

6

Ho già una solida autorizzazione per i permessi di back-end (ad esempio, l'amministratore può eseguire un'azione, un utente normale non può eseguire un'azione). Tuttavia, mi chiedo se esiste un modo migliore per eseguire un'autorizzazione di frontend per la mia applicazione JavaScript a pagina singola, recuperando quindi un'autorizzazione dall'API ogni vista.

Sembra che potrei:

a. Hai un modo globale per dire che tipo di utente è?

Potrei farlo, ma se le autorizzazioni cambiano nel back-end dovrei aggiornare chi può vedere cosa sul front-end.

b. Controlla i permessi su ogni vista?

Sembra solo un sacco di richieste API

c. Crea un'app separata per un Dashboard?

In questo modo ho potuto conoscere tutte le autorizzazioni correnti dell'utente senza che un normale utente tornasse a guardarsi intorno.

Potrei aver risposto alla mia domanda con c ma se qualcuno pensa ad un'idea migliore mi piacerebbe sentirla.

javascript client-side authorization

posta Christian Pavilonis 23.04.2018 - 16:15

fonte

4 risposte

Leggi altre domande sui tag javascript client-side authorization

Ordine file di intestazione C Scomporre un monolite in SOA e infrangere l'integrità referenziale

score 5 · Answer 1

Dipende da cosa intendi per "permessi". Presenterò alcune idee con un esempio con le risorse User e Project.

Se le autorizzazioni sono indipendenti da un determinato Progetto, allora stai realmente parlando dell'Utente con un ruolo (ad es. admin). Questo può essere codificato nella rappresentazione API di tale utente.

Se le autorizzazioni dipendono dalla risorsa sottostante (ad esempio, un utente può disporre di autorizzazioni diverse per un determinato progetto), queste possono risiedere nella rappresentazione dell'API per tale risorsa. Questo ha il pro che non hai bisogno di un enorme dizionario di tutte le autorizzazioni di un utente e il fatto che qualsiasi caching di quella risorsa debba essere specifica dell'utente. Questo potrebbe essere un compromesso accettabile.

Hai ancora un potenziale problema di usabilità con dati obsoleti se qualcuno carica una vista e le relative autorizzazioni per la modifica della risorsa visualizzata prima che tentino un'azione. Un modo per cercare di mitigare questo è utilizzare i websocket per inviare aggiornamenti alle risorse visualizzate per provare a ridurre la finestra durante la quale l'interfaccia utente non sarà aggiornata con il database di back-end.

score 3 · Answer 2

Ci sono molte opzioni per farlo. Ho usato un approccio che consiste in:

Chiama l'API per ottenere l'elenco delle autorizzazioni quando la pagina viene caricata per la prima volta; Cache i risultati.
Prima di eseguire il routing a un'API di chiamata di visualizzazione che interroga l'ultimo aggiornamento delle concessioni dell'utente, restituisce solo il timestamp.
Se c'è un cambiamento, chiama l'API per ottenere le autorizzazioni aggiornate dopo il timestamp dell'ultima modifica.

score 1 · Answer 3

1

Un approccio sarebbe quello di salvare tutte le autorizzazioni dell'utente nella memoria locale, creare un wrapper attorno a esso e mostrare / nascondere la base di ciò che lui o lei può fare.

risposta data 23.04.2018 - 17:17

fonte

score 0 · Answer 4

Una soluzione è generare un segno (come in crittografia asimmetrica) un token di autorizzazione sul lato server, poiché è firmato, non può essere manomesso poiché un utente malintenzionato non conosce la chiave privata.

vale a dire. Il token potrebbe avere un aspetto simile a:

id: userId
type: type of user
privileges: {
    privilege1,
    privilege2
}
expiry: some time in the near future, after which your app should request a new token

Dovresti quindi firmarlo sul server, usando una chiave privata. La chiave pubblica liberamente distribuita consente a chiunque di verificare che il server è stato colui che ha emesso il token, e quindi la tua app javascript può tranquillamente utilizzare il token per determinare a cosa l'utente ha accesso.