Vynutit přihlášení se stává výchozím nastavením pro všechny REST Auth

Automaticky přeloženo z Deepl

Nedávno jsme poskytli nový způsob řízení přístupu k rozhraní REST API prostřednictvím oprávnění a funkce ds.authentify: Vynutit přihlášení. Tato funkce nabízí mnohem více než dříve dostupné mechanismy ověřování a byla jasně vysvětlena v tomto příspěvku na blogu.

Ve verzi 4D 20 R6 je nyní Force Login výchozím režimem pro ověřování REST. Zajímá vás, proč a jak tento přechod řešit? Pokračujte ve čtení tohoto příspěvku.

Výchozí nastavení v nových projektech

Při vytváření projektu v aplikaci 4D 20 R6 se ve složce Sources automaticky vytvoří soubor roles.json. Tento soubor obsahuje atribut forceLogin nastavený na hodnotu„True“ a oprávnění„none „, které ve výchozím nastavení zamezuje přístup k celému rozhraní REST API.

Tento přístup zajišťuje vysokou úroveň zabezpečení již od návrhu.

Oprávnění můžete přizpůsobit úpravou poskytnutého souboru roles.json nebo pomocí editoru Qodly Studio Roles and Privileges, který je uživatelsky přívětivější.

Nyní můžete jemně kontrolovat přístup REST k vašim datům a funkcím!

Co se stávajícími projekty?

U stávajících projektů vám nové tlačítko na kartě Web/Web Features v dialogovém okně Nastavení struktury umožňuje převést projekt na funkci Force Login.

Kliknutím na toto tlačítko 4D:

  • odstraní skupinu uživatelů s přístupem pro čtení/zápis do rozhraní REST API z nastavení.
  • Přesune databázovou metodu „On REST Authentication“ do systémového koše.
  • Vytvoří soubor „roles.json“ ve složce Sources, pokud ještě neexistuje, a nastaví jeho atribut forceLogin na hodnotu True.

Po provedení této konverze nezapomeňte restartovat projekt. Pokud se tlačítko nezobrazí, váš projekt je již kompatibilní s funkcí Force Login.

Přechod ze starších nastavení

Do zavedení funkce Force Login jste měli tři možnosti řízení přístupu REST. Níže vám vysvětlíme, jak je všechny napodobit, když je Force Login povoleno.

V těchto příkladech budeme používat oprávnění „Administrator“ vytvořené v editoru Qodly Studio Roles and Privileges: blank

1: Server vystavený jako Rest bez skupiny přístupu

První možnost spočívala v vystavení serveru REST bez definování přístupové skupiny nebo filtrování požadavků v databázové metodě „On REST Authentication“.
Chcete-li reprodukovat toto chování pomocí funkce Vynutit přihlášení, musíte jednoduše udělit plný přístup k celému rozhraní REST API:

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

Upozorňujeme, že tuto implementaci nedoporučujeme, protože postrádá zabezpečení. Všechna data a funkce jsou přístupné všem.

2: Server vystavený jako Rest s definovanou skupinou přístupu.

Druhou možností bylo definovat skupinu uživatelů 4D s přístupem Read/Write k rozhraní REST API.
Chcete-li reprodukovat toto chování, stačí zkontrolovat pověření a udělit plný přístup členům skupiny Read/Write, která byla definována v dialogu Nastavení struktury (v tomto příkladu skupina „RestAccess“):

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

Toto omezení zabezpečuje přístup k datům a funkcím proti škodlivým připojením. Každé autorizované připojení má stejná práva.

3: metoda ověřování v klidovém stavu

Třetí možností bylo ověřit pověření uživatele pomocí databázové metody „On REST Authentication“. Tato metoda se často používala ke kontrole přístupů z vlastního systému správy uživatelů. Chcete-li reprodukovat toto chování, můžete kód metody „On REST Authentication“ téměř zkopírovat do funkce ds.authentify(), jako v tomto příkladu.

Původní metoda „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

Nahrazení funkce „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("Administrator")
End if
End if
End if

Stejně jako u předchozí možnosti má každé autorizované připojení stejná práva; přístup k datům a funkcím bylo třeba zakódovat podle svého.

Další úroveň

Síla funkce Force Login spočívá v tom, že na připojení REST můžete aplikovat stejnou obchodní logiku a omezení, jaká chcete. To platí zejména pro požadavky z Qodly Pages, připojení ke vzdálenému datovému úložišti nebo externí požadavky REST.
V následujícím příkladu místo definování oprávnění „Administrator“ při ověřování uživatele jednoduše nastavíme oprávnění uložená v entitě uživatele. To vám umožní poskytnout jemný přístup k datovému skladu, datovým třídám, atributům datových tříd a funkcím, které chcete, a omezit vše ostatní!

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

Na závěr

Force Login poskytuje přesnou kontrolu nad přístupem k vašim datům a funkcím z rozhraní REST API. Umožňuje deportovat logiku přístupu z kódu na definovaná oprávnění, čímž se vyhnete přehlédnutí kódu při přístupu a následně nabídne spolehlivější úroveň zabezpečení. Tato integrovaná vrstva zabezpečení je mnohem přesnější, protože můžete definovat oprávnění pro každý prvek datového skladu (samotný datový sklad, datové třídy, atributy datových tříd, funkce) a každému z nich přidělit práva (Vytvořit, Číst, Aktualizovat, Odstranit atd.).
Definujte svá oprávnění a využijte editor Qodly Studio Roles and Privileges, který vám poskytne lepší zážitek.
Podělte se o své názory na tuto funkci na fóru 4D!

Avatar
• Product Owner • Damien Fuzeau se připojil k týmu 4D Product v únoru 2019. Jako Product Owner má na starosti psaní uživatelských příběhů a jejich následný převod do funkčních specifikací. Jeho úkolem je také zajistit, aby dodávané implementace funkcí vyhovovaly potřebám zákazníků. Damien vystudoval softwarové inženýrství na University of Nantes. Ve své bývalé společnosti strávil více než 23 let, nejprve jako vývojář (objevil 4D v roce 1997) a později jako technický manažer a softwarový architekt. Tato společnost je partnerem 4D OEM a nasadila obchodní software založený na 4D pro tisíce uživatelů na stovkách serverů. Damien je tedy zvyklý na 4D vývoj a nasazení ve vícejazyčném kontextu.