As a part of app security, you can secure pages and UI elements—widgets or parts of widgets. Security for the UI determines whether a user can see something (or hear it with a screen reader).
How can I secure my app’s UI?
Using App Maker, you can use one or both of these approaches to secure your app’s UI:
- Secure pages—Use page security to control which pages users can see. In the Property Editor , under Security, apply Roles or Script access permissions to each page.
- Secure UI elements—Use the
visibleproperty to control which elements on a page users can see. The visible property is available for widgets and for parts of compound widgets. In the Property Editor , under Display, define a binding expression for the UI element that resolves to
Set up page security to control which users can access which app pages.
Why secure pages?
- Restrict access to sensitive static information—In some cases, pages might display static information that only specific users should be able to view. For example, a page might display a secret recipe for dog food.
- Restrict use of pages to those who need them—If specific sets of users have different jobs, then restricting pages to the sets of users who use the pages makes sense. There might be no reason to give non-administrators access to pages that are used by administrators.
- Securing pages has performance benefits—Controlling whether users can access pages has performance benefits. If App Maker doesn’t need to fetch unneeded pages and related data for a user who shouldn’t have access to the pages and data anyway, then less data travels back and forth.
Set access permissions for a page
Page security uses access permissions. Access permissions that are available for pages are Admins Only, Everyone, Roles, and Script.
- Open App Maker.
- In the left sidebar, click the page for which you want to set permissions.
- In the Property Editor , under Security, select the access permission for the page from the list.
How does App Maker control access to a page?
- Retrieval—App Maker uses page permissions to decide whether to retrieve a specific page for a user. If a user shouldn’t have access to a page, App Maker doesn’t retrieve the page. Because an App Maker app is a web app, App Maker doesn’t acknowledge that the page exists. It responds with a Page Not Found error (HTTP 404). App Maker doesn’t list the page in menus. You can also design navigation in your app to omit links to the page for users that shouldn’t have access to the page.
- Viewing—If a page hasn’t been retrieved, then a user can’t see it or read it with a page reader.
- DOM—A page that App Maker doesn’t retrieve for a user is not in the DOM.
Refer to pages
References to pages have important aspects:
- References to the pages in an app—In a menu, when you reference the pages in an app (for example, with the binding expression
@pagesor with a reference in a script to
app.pages), App Maker only lists the pages that the user should have access to.
- Links to a page—You can control the visibility of UI elements that link to pages (for example, links).
- URL of a page—A user could obtain the URL of a page to which the user doesn’t have access from a different user. Or, a user could bookmark a URL and then lose access to that part of the app.
- References to the page in the DOM—Because pages in the app can refer to other pages (for example, using links), a savvy user might be able to find references in the DOM to a page to which the user doesn’t have access.
Control the visibility of UI elements
You can use the
visible property to control whether UI elements (widgets or parts of widgets) on a page are visible for specific users. Reasons to control visibility include:
- Relevance—If some content or navigation controls aren’t relevant in a specific situation or for a specific user, then don’t use them on a page. For example, a link to edit a record only makes sense if the record exists. If the record doesn’t exist, you could hide the link. Visibility can also be data driven.
- Security—If a user shouldn’t be able to use a specific UI element, then you can hide the element for that user.
Write a binding expression that evaluates to Boolean
For security, write a binding expression for the
visible property of a UI element that invokes a security measure and that evaluates to the Boolean result
false. You can take these approaches:
In the binding expression, reference roles for which members of the roles should have access. This example gives access to members of the group Managers:
(@user.roles).indexOf('Managers') > -1
Call a method in a client script that calls a method in a server script. Use the method in the server script to make the visibility determination based on any criteria; for example, on the basis of role membership or data. The server method can return
falseto the client method, which can return the value.
Use automatic type conversions
App Maker needs a Boolean result for the
visible property. If a binding expression returns
false, then App Maker uses the supplied value.
A binding expression for the
visible property can also bind to a field of type Number or String, or can call a function that returns a number or string. In these cases, App Maker performs a type conversion, converting the number or string to a Boolean value. You can’t bind to a field of type Date. If a function returns a date, the date is handled as a string.
The conversions performed are the same as if you used the binding transformers
strToBool(). (You can use the binding transformers, though you don’t need to.)
The automatic type conversions for numbers and those performed by
But type conversions performed for strings and by
Here’s what you need to know:
|Field type||True (Visible)||False (Invisible)|
|Value: box is checked
||Value: box is unchecked
All other values not listed under False; for example, 2, 208.1, -7, Infinity, -Infinity
All other values not listed under True; for example, "employee", or "admin".
Control visibility in widget hierarchies
Widgets are often hierarchical. A form has a title, text boxes for entering or choosing data, and so on. You can control the visibility of the entire widget, of parts of the widget, or both.
In a hierarchy, a
false value of a
visible property makes that UI element and every UI element below it in the hierarchy invisible.