Secure the UI

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 edit , under Security, apply Roles or Script access permissions to each page.
  • Secure UI elements—Use the visible property 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 edit , under Display, define a binding expression for the UI element that resolves to true (visible) or false (invisible).

Secure pages

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.

  1. Open App Maker.
  2. In the left sidebar, click the page for which you want to set permissions.
  3. In the Property Editor edit , 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 @pages or 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 true or 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 true or false to 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 true or 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 numToBool() and strToBool(). (You can use the binding transformers, though you don’t need to.)

The automatic type conversions for numbers and those performed by numToBool() match JavaScript type conversions. Type conversions for special cases (undefined, null, and NaN) also match JavaScript type conversions (all convert to false).

But type conversions performed for strings and by strToBool() don’t match JavaScript type conversions.

Here’s what you need to know:

Field type True (Visible) False (Invisible)

(matches JavaScript)
Value: box is checked
Value: box is unchecked

(matches JavaScript)
1, 1.0
All other values not listed under False; for example, 2, 208.1, -7, Infinity, -Infinity
0, -0, 0.0, -0.0

(doesn’t match JavaScript)
"true", "True", "TRUE"... (any case) "false", "False", "FALSE"... (any case)
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.