Scoprite qui come, nei processi web, potete proteggere le vostre risorse (dati + logica aziendale) da accessi dannosi e da utenti non autorizzati… in un solo clic.
In modalità di sviluppo, impostate la proprietà Restrict access by default su FALSE per concentrarvi sull’organizzazione del codice, sul modello dei dati, sull’architettura delle pagine Qodly, sui test… senza alcuna restrizione all’uso dei dati o alla chiamata di funzioni.
Quando si è pronti a implementare i profili utente, basta impostare la proprietà Restrict access by default su TRUE per garantire che nessuno acceda ai dati e alla logica aziendale senza essere esplicitamente autorizzato.
Promemoria
Da 4D 20, 4D offre un sistema potente e completamente personalizzabile per proteggere le risorse (dati e logica aziendale) da utenti non autorizzati.
Questo sistema offre un livello di granularità personalizzabile e si basa sulla presenza di privilegi nella sessione. I privilegi devono essere impostati nel file roles.json e autorizzati a eseguire alcune azioni (lettura, creazione, …) su alcune risorse (classi di dati, attributi, funzioni).
I privilegi si applicano ai processi web che utilizzano sessioni web scalabili, ad es: richieste REST, datastore remoti, applicazioni Qodly.
Quando all’utente viene concesso di entrare nell’applicazione, l’implementazione dell’autenticazione deve inserire i privilegi appropriati nella sessione.
Quindi, quando l’applicazione riceve una richiesta web, viene effettuato un controllo sulla presenza di privilegi nella sessione. Solo le azioni autorizzate possono essere eseguite.
Se l’azione sulla risorsa non è consentita, viene segnalato un errore di autorizzazione.
la proprietà Limita accesso per impostazione predefinita
Con la 4D21, nel file roles.json è disponibile una nuova proprietà booleana: restrictedByDefault.
Permette di impostare il comportamento predefinito per quanto riguarda gli accessi web alle risorse sottostanti:
- il datastore
- una classe di dati
- un attributo
- una funzione della classe del modello di dati
- una funzione singleton
Questo ha un impatto solo sulle risorse per le quali non sono state impostate le autorizzazioni.
Se FALSO: le risorse sono accessibili per impostazione predefinita.
Se non si impostano permessi, tutte le risorse sono accessibili per qualsiasi azione di creazione, lettura, aggiornamento…
Se si impostano i permessi, tutte le risorse non coinvolte nei permessi rimangono accessibili.
Se VERO: l’accesso alle risorse è limitato per impostazione predefinita.
Se non si impostano permessi, nessuna risorsa è accessibile.
Se si impostano i permessi, tutte le risorse non coinvolte nei permessi rimangono inaccessibili.
L’interfaccia di Qodly Ruoli e privilegi
Forse avete già utilizzato l’interfaccia Ruoli e privilegi dello studio Qodly. Offre un’interfaccia intuitiva per impostare i permessi della vostra applicazione. Questa interfaccia offre ora la possibilità di aggiornare la proprietà Limita accesso per impostazione predefinita.
con versioni precedenti di 4D
Se l’applicazione viene eseguita con una versione precedente di 4D, è equivalente ad avere restrictedByDefault impostato su FALSE. È possibile ottenere un livello di sicurezza simile creando un privilegio all, che consente di eseguire tutte le azioni sul Datastore.
E non dare mai questo privilegio all a nessun utente.
Avvio di un nuovo progetto
Quando si crea un nuovo progetto, il file roles.json viene impostato così com’è:
Poiché restrictedByDefault è False, questo aiuta ad avviare un nuovo sviluppo. Ci si può concentrare sul codice, sulla progettazione dei moduli, sulle chiamate di funzione e sull’accesso ai dati senza essere ostacolati.
pratica migliore
Per una sicurezza ottimale, quando si è pronti a implementare i profili utente, si consiglia di impostare la proprietà restrictedByDefault su True e di impostare i privilegi in modo da garantire:
–le risorse sono protette da accessi esterni dannosi
– aogni utente è concesso di eseguire solo azioni autorizzate sui dati consentiti
esempio
Nell’esempio seguente, il modello di dati è:
Nel file roles.json:
quindi:
– è impossibile accedere alla classe di dati SecretInfos (lettura, creazione, aggiornamento, …)
– il privilegio viewPeople è necessario per leggere la classe di dati People, mentre le altre azioni sulla classe di dati People non sono concesse.
L’HDI allegato lo dimostra.
Non aspettate a impostare i permessi per proteggere la vostra applicazione e i vostri dati, gestendo profili utente accurati e appropriati.