ORDA – Omezit data na relevantní kritéria

Automaticky přeloženo z Deepl

Ve verzi 4D 19 R8 jsme zavedli robustní systém oprávnění, který vám umožní detailní kontrolu nad přístupem uživatelů k vašim datům. Tento systém chrání vaše data v závislosti na tom, kdo k nim přistupuje a ke kterým datům, a zajišťuje tak bezpečnost dat omezením neoprávněného přístupu.

Co kdybyste ale chtěli přístup ke čtení dále zpřesnit na základě konkrétních kritérií?

V tom případě přichází na řadu 4D 20 R5. Omezení čtení dat podle určitých kritérií.

HDI Omezit data

praktický případ použití

Díky systému oprávnění můžete udělit přístup ke čtení datové třídy Customers jen některým uživatelům s příslušným oprávněním. To je velmi dobré, ale pokud je povoleno čtení datové třídy Customers, může uživatel číst VŠECHNY zákazníky.

Představte si například aplikaci, kterou používají prodejci k uzavírání obchodů se svými zákazníky. Abyste ochránili důvěrnost, mohli byste omezit čtení zákazníků pouze na ty, které spravuje ověřený prodejce.

Samozřejmě byste to mohli udělat sami pomocí vlastní implementace, ale to by mohlo vést k těžkopádnému a obtížně udržovatelnému kódu. V kódu musíte své omezení uplatnit na každém místě čtení dat.

Zapomeňte na to a zapište své kritérium omezení jednou na jediném místě, a to je vše!

Jak toto omezení implementovat

Jak prozrazuje název, filtr se vztahuje pouze na data načtená pomocí ORDA a dotazy zpracovávané pomocí klasického 4D se neberou v úvahu.

V příslušné třídě datové třídy je třeba pomocí klíčového slova event. restrict() funkci. Tato funkce musí vracet výběr entit dotčené datové třídy.

V implementaci vytvoříte výběr entit, který bude použit jako omezující filtr při čtení dat z této datové třídy pomocí některých funkcí, jako např. query() nebo all(). Podrobněji se podívejte do dokumentace, kde najdete všechny ostatní funkce, kterých se použitý filtr týká.

Níže je uveden příklad představující aplikaci, kterou používají prodejci k uzavírání obchodů se zákazníky. Omezíme čtení zákazníků na ty, které spravuje prodejce používající aplikaci.

Tato aplikace se používá ve dvou kontextech:

  • jako webový server
  • v režimu klient-server

Nejprve je zde uveden datový model:

Zde je třída datové třídy Customers:


Class extends DataClass

Function event restrict() : cs.CustomersSelection
	
// There is a session
If (Session#Null)
		
	Case of 
		: (Session.storage.salesInfo#Null)
		// Only the customers handled by the authenticated salesperson are returned
		return This.query("sales.internalId = :1"; Session.storage.salesInfo.internalId)
				
		// Data explorer 
		: (Session.hasPrivilege("WebAdmin"))
		//No filter is applied
		return Null
				
		Else 
		//No customers can be read
		return This.newSelection()
	End case 
		
Else 
	//No customers can be read
	return This.newSelection()
End if

Objekt Session je k dispozici ve webovém kontextu, ale také v kontextu C/S (viz tato nová funkce).

  • Prodejce se ověřil pomocí identifikátoru a hesla. Interní identifikátor ověřeného prodejce je uložen v objektu Session. V restrict() funkci vracíme pouze zákazníky spravované tímto ověřeným prodejcem.
  • V ostatních případech z bezpečnostních důvodů vracíme prázdný výběr entity Customers, abychom zabránili čtení zákazníků.

tento příklad v akci

Vewebovém kontextu byl ověřený prodejce internalId uložen v relaci Session. Při spuštění požadavku /rest/Customers na webové stránce lze číst pouze jeho zákazníky:

blank

Vkontextu klient-server je díky novému objektu Session, který je k dispozici v C/S, ověřený prodejce také uložen v relaci.

Když klikneme na tlačítko Získat všechny zákazníky, zavolá se funkce Customers.all() a použije se stejný filtr.

blank

Stáhněte si HDI a dále objevujte tuto výkonnou funkci!

Avatar
• Product Owner • Marie-Sophie Landrieu-Yvert se připojila k programovému týmu 4D jako Product Owner v roce 2017. Jako Product Owner má na starosti psaní uživatelských příběhů a jejich převod do funkčních specifikací. Její úlohou je také zajistit, aby implementovaná funkce odpovídala potřebám zákazníka. Marie-Sophie vystudovala inženýrskou školu ESIGELEC a svou kariéru zahájila jako inženýrka v IBM v roce 1995. Podílela se na různých projektech (projekty údržby nebo výstavby) a pracovala jako vývojářka Cobol. Poté pracovala jako UML designer a Java developer. V poslední době byly jejími hlavními rolí analyzovat a psát funkčních požadavky a koordinovat obchodní a vývojové týmy.