Permissions & Access Control

Permissions & Access Control

Security in the Application Designer works at two levels: who can open an app, and what an app is allowed to do. Both are enforced by the platform, not by app code.

App-level permissions

Each app can be assigned a permission. Only users who hold that permission see the app in their menu and can open it — on the web, inside Plex, or on mobile. Apps without a permission are open to anyone who can reach the surface. List the permissions available to gate apps with apps_list_available_permissions.

Resource-level authorization

An app may only use the lookup tables, ODBC queries, scripts, serial series, and printers it declares. That declared list becomes the app's published manifest, and the manifest is the authorization surface: every data query, script run, serial generation, and print is checked against it on the server. A call to anything not declared is refused with not_declared.

This is deliberate: the list you use for editor autocomplete is the exact same list the server authorizes against. There is no separate, hidden surface to keep in sync.

The SPA sandbox

Custom Vue SPA apps add a hard isolation boundary. The app runs in a sandboxed iframe with an opaque origin:

• Your code never holds a session or token.
• Direct network access is blocked by Content-Security-Policy (connect-src 'none') — no fetch, XHR, or WebSocket to arbitrary hosts.
• Every platform call goes through the @datamagik/app-sdk bridge, which the trusted host page proxies to app-scoped APIs with server-side authorization on each request.

The result: even fully custom code can only reach the resources its manifest permits.

Builder access & API keys

Creating and publishing apps requires the Builder permission. The CLI authenticates with an API key (a dcp_ token) that you create in the platform UI under your profile's API Keys and paste into dm login. See Installing & Using the CLI.