Security policy rule

Introduction

Access rules control user access to worker sites, pages, and widgets with a boolean result (true/false). However, boolean logic is not sufficient when you need finer-grained control — for example, making a page read-only for some users but fully editable for others. Security policy rules address this by returning an access mode instead of a boolean.

Security policy rules provide:

• Inheritance — child resources inherit the parent's security policy automatically.
• Overrides — children can override the inherited policy when needed.
• Broad applicability — security policies can be applied to pages, widgets, and widget actions.

Rule syntax

Keywords

The following keywords are available in security policy rules:

Name	Type	Description
@user	DslUser	The user in context.
@apiFactory	IManagedApiFactory	To construct Casewhere API objects. Read here for the full list of available APIs.
@parameters	dynamic	Dictionary of parameter objects passed into the rule for verifying context.
@parentAccessMode	AccessMode?	The access mode result of the parent resource. Available when the resource inherits from its parent.

DslUser

Name	Type	Description
UserId	string	The ID of the user.
Username	string	The username used for login.
Has	bool (string claimType)	Determines whether the user has a specific claim.
Contains	bool (string claimType, string value)	Determines whether the user has a specific claim value.
GetClaim	string (string claimType)	Returns the first value of the specified claim type.
this[key]	ClaimValueList	Indexer that returns all values for the specified claim type. ClaimValueList extends List<string> with a Join() method.
WorkerSite	DslWorkerSite	The worker site in context.

DslWorkerSite

Name	Type	Description
Id	Guid	The unique identifier of the worker site.
Name	string	The name of the worker site. Must be unique.
Title	string	The display title of the worker site.
DomainName	string	The domain of the worker site.
DefaultLanguageId	string	The default language identifier for the worker site.
TimezoneId	string	The standard name of the timezone from TimeZoneInfo.GetSystemTimeZones. For example, "Romance Standard Time".
TimezoneOffset	double	The time difference in minutes between the worker site's timezone and UTC.
ShortDate	string	The short date format (e.g., "dd.MM.yyyy").
LongDate	string	The long date format (e.g., "dd.MM.yyyy HH:mm").
DecimalSeparator	string	The decimal separator ("," or "." depending on configuration).
ThousandSeparator	string	The thousand separator ("," or "." depending on configuration).
IsHttps	bool	Whether the worker site uses HTTPS.
EnableAnonymousUser	bool	Whether anonymous user access is enabled.
ProductId	string	The product identifier associated with the worker site.
IsUnderMaintenance	bool	Whether the worker site is currently under maintenance.
IdPConnection	string	The identity provider connection name.

Access modes

Security policy rules return one of the following access modes:

Name	Type	Description
Read	string	The user can read the resource.
Write	string	The user can read and write the resource.
Deny	string	The user cannot access the resource.

Compatibility and effect

Access rule	Security policy rule	Context	Description
true	AccessMode.Read/Write	Pages	Show on UI
false	AccessMode.Deny	Pages	Unauthorized error
true	AccessMode.Read/Write	Widget	Show on UI
false	AccessMode.Deny	Widget	Hide on UI
true	AccessMode.Write	Widget Action	Show on UI and executable
	AccessMode.Read	Widget Action	Show on UI and non-executable
false	AccessMode.Deny	Widget Action	Hide on UI

Examples

Example 1: Role-based access control

Only users with the "admin" role get write access; everyone else gets read-only access.

Single line:

@user.Contains("Roles", "admin") ? AccessMode.Write : AccessMode.Read;

Multi-line:

#predicate
if (@user.Contains("Roles", "admin"))
{
return AccessMode.Write;
}
// other logic
return AccessMode.Read;

Example 2: Whitelist-based access

Only whitelisted users can access the resource.

#predicate
 
var dataApi = @apiFactory.Get<IDataApi>();
var filter = FilterBuilder.Create().Eq("Username", @user.Username).Eq("Active", true).Build();
var found = dataApi.Any("WhitelistedUsers", filter);
 
return found ? AccessMode.Read : AccessMode.Deny;

Example 3: Parameter-based access

Read input parameters via @parameters to verify access.

#predicate

if (!@parameters.Has("UserName")) 
{
return AccessMode.Deny;
}

var dataApi = @apiFactory.Get<IDataApi>();
var userName = @parameters["UserName"];
var filter = FilterBuilder.Create().Eq("Username", userName).Eq("Active", true).Build();
var found = dataApi.Any("WhitelistedUsers", filter);
 
return found ? AccessMode.Read : AccessMode.Deny;

Example 4: Inherit from parent

Access the parent resource's security policy via @parentAccessMode.

#predicate

if (@parentAccessMode != null && @parentAccessMode == AccessMode.Deny) 
{
// If parent denied access, deny the child as well
return AccessMode.Deny;
}

// handle other logic
// ...
return AccessMode.Read;

How to apply security policy rules

To apply security policy rules for pages, widgets, and widget actions, go to the Security tab in the edit resource panel.

• Can inherit from parent — when enabled, child resources inherit the parent's security policy. Children can override the inherited policy if needed.

• You can Add new rule or Select multiple rules. Rules are combined with the logical AND operator (including the inherited parent result):

  • If any rule returns Deny, the user is denied access.
  • If no rules are assigned, the resource defaults to Write access mode.

Page

Security policy rules on pages control not only page access but also how the page's widgets and widget actions behave — whether they are visible, editable, or executable.

Example

A security policy rule that grants write access to admins and managers, read-only access to regular users, and denies all others:

#predicate

if (@user.Contains("Roles", "Admin") ||
@user.Contains("Roles", "Manager")) 
{
return AccessMode.Write;
}

if (@user.Contains("Roles", "User")) 
{
return AccessMode.Read;
}

return AccessMode.Deny;

You can access the page's access mode on the client side via page script or events:

$scope.accessMode
// "Read"

Widget and widget actions

Security policy rules for widgets and widget actions work the same way as for pages. A widget's security policy applies to all its widget actions.

You can use the widget's context for fine-grained control — for example, allowing view-only access to a widget but restricting specific actions.

To access the widget's access mode on the client side:

// Access mode of Widget
$scope.widgetApis['widget-name'].getAccessMode()
// or
$scope.widgets['widget-name'].accessMode
// "Read"

// Access mode of Widget action
$scope.widgets['widget-name'].actions[0].accessMode
// "Write"