Di recente abbiamo fornito un nuovo modo di controllare l’accesso all’API REST tramite i privilegi e la funzione ds.authentify: Forza il login. Questa funzione offre molto di più rispetto ai meccanismi di autenticazione precedentemente disponibili ed è stata spiegata chiaramente in questo post del blog.

Con 4D 20 R6, Force Login è ora la modalità predefinita per le autenticazioni REST. Vi state chiedendo perché e come gestire questa transizione? Continuate a leggere questo post.

Predefinito nei nuovi progetti

Quando si crea un progetto in 4D 20 R6, viene creato automaticamente un file roles.json nella cartella Sources. Questo file include l’attributo forceLogin impostato su“True” e un privilegio“none“, che nega l’accesso all’intera API REST per impostazione predefinita.

Questo approccio garantisce un elevato livello di sicurezza.

È possibile personalizzare i permessi modificando il file roles.json fornito o utilizzando l’editor di ruoli e privilegi di Qodly Studio per un’esperienza più semplice.

Ora siete in grado di controllare con precisione l’accesso REST ai vostri dati e alle vostre funzioni!

E i progetti esistenti?

Per i progetti esistenti, un nuovo pulsante nella scheda Caratteristiche Web/Web della finestra di dialogo Impostazioni struttura consente di convertire il progetto in Accesso forzato.

Facendo clic su questo pulsante, 4D

• Rimuovere dalle impostazioni il gruppo di utenti con accesso in lettura/scrittura all’API REST.
• Sposta il metodo di database “On REST Authentication” nel cestino del sistema.
• Crea un file “roles.json” nella cartella Sources, se non esiste già, impostando l’attributo forceLogin su True.

Ricordarsi di riavviare il progetto dopo aver eseguito questa conversione. Se il pulsante non viene visualizzato, il progetto è già compatibile con Force Login.

Passare dalle impostazioni precedenti

Prima dell’introduzione di Force Login, esistevano tre opzioni per il controllo degli accessi REST. Di seguito spieghiamo come imitare tutte queste opzioni quando Force Login è abilitato.

In questi esempi, utilizzeremo un privilegio “Amministratore” creato nell’editor Ruoli e privilegi di Qodly Studio:

1: Server esposto come Rest senza gruppo di accesso

La prima opzione consisteva nell’esporre il server REST senza definire un gruppo di accesso o filtrare le richieste nel metodo di database “On REST Authentication”.
Per riprodurre questo comportamento con Force Login, è sufficiente dare accesso completo all’intera API REST:

Class extends DataStoreImplementation
exposed Function authentify() : Boolean
return Session .setPrivileges("Amministratore")


Si noti che questa implementazione non è consigliata perché manca di sicurezza. Tutti i dati e le funzioni sono accessibili a tutti.

2: Server esposto come Rest con gruppo di accesso definito

La seconda opzione consiste nel definire un gruppo di utenti 4D con accesso in lettura/scrittura all’API REST.
Per riprodurre questo comportamento, è sufficiente controllare le credenziali e dare pieno accesso ai membri del gruppo Lettura/Scrittura definito nella finestra di dialogo Impostazioni struttura (il gruppo “RestAccess” in questo esempio):

Class extends DataStoreImplementation
exposed Function authentify Session($identifier: Text; $pwd: Text) : Boolean
If ($identifier#")
If (Validate password($identifier; $pwd)
If (User in group($identifier; "RestAccess"))
return .setPrivileges("Administrator")
End if
End if
End if


Questa restrizione protegge l’accesso ai dati e alle funzioni da connessioni dannose. Ogni connessione autorizzata ha gli stessi diritti.

3: metodo di autenticazione a riposo

La terza opzione consisteva nel verificare le credenziali dell’utente utilizzando il metodo di database “On REST Authentication”. Questo metodo è stato spesso utilizzato per verificare gli accessi da un sistema di gestione utenti personalizzato. Per riprodurre questo comportamento, è possibile copiare il codice del metodo “On REST Authentication” nella funzione ds.authentify(), come in questo esempio.

Il metodo originale “On REST Authentication”:

#DECLARE($identifier: Text; $pwd: Text) : Boolean
If ($identifier#")
var $user : cs.UserEntity:=ds.User.query("identifier = :1"; $identifier).first()
If ($user#Null)
If (Verify password hash($pwd; $user.pwd))
return True
End if
End if
End if


La sostituzione della funzione “ds.authentify()”:

Class extends DataStoreImplementation
exposed Function authentify($identifier: Text; $pwd: Text) : Boolean
If ($identifier#")
var $user : cs.UserEntity:=ds.User.query("identifier = :1"; $identifier).first()
If ($user#Null)
If (Verify password hash($pwd; $user.pwd))
return Session.setPrivileges("Amministratore")
End if
End if
End if


Come per l’opzione precedente, ogni connessione autorizzata ha gli stessi diritti; l’accesso ai dati e alle funzioni deve essere codificato dall’utente.

Livello successivo

La potenza di Force Login consiste nel fatto che è possibile applicare la stessa logica aziendale e le stesse restrizioni desiderate alle connessioni REST. Ciò è particolarmente vero per le richieste provenienti da pagine Qodly, connessioni a datastore remoti o richieste REST esterne.
Nell’esempio seguente, invece di definire il privilegio “Amministratore” quando l’utente viene autenticato, si impostano semplicemente i privilegi memorizzati nell’entità utente. In questo modo è possibile dare un accesso a grana fine al datastore, alle classi di dati, agli attributi delle classi di dati e alle funzioni desiderate e limitare tutto il resto!

Class extends DataStoreImplementation
exposed Function authentify($credentials: Object) : Boolean
If ($credentials#Null)
var $user : cs.UserEntity:=ds.User.query("identifier = :1"; $credentials.identifier).first()
If ($user#Null)
If (Verify password hash($credentials.pwd; $user.pwd))
return Session.setPrivileges($user.privileges)
End if
End if
End if


Per concludere

Force Login fornisce un controllo preciso sull’accesso ai dati e alle funzioni dell’API REST. Consente di trasferire la logica di accesso dal codice a permessi definiti, evitando così sviste del codice sull’accesso e offrendo un livello di sicurezza più affidabile. Questo livello di sicurezza integrato è molto più preciso, perché è possibile definire le autorizzazioni per ogni elemento del datastore (datastore stesso, classi di dati, attributi di classi di dati, funzioni) e attribuire a ciascuno di essi dei diritti (creazione, lettura, aggiornamento, cancellazione, ecc.).
Definite i vostri privilegi e utilizzate l’editor dei ruoli e dei privilegi di Qodly Studio per una migliore esperienza.
Condividete il vostro feedback su questa funzione sui Forum 4D!