Skip to content

Kiosk mode ​

Kiosk mode shows a custom app full-screen instead of the CoCoCo console. It is meant for shared screens such as shop-floor terminals and station tablets, where a person should see one focused task and nothing else.

A kiosk setup has three parts:

  1. A kiosk user account: a user of kind KIOSK.
  2. One or more custom apps of kind KIOSK.
  3. Bindings that assign those apps to the kiosk account.

Kiosk user accounts ​

KIOSK is one of the three user account kinds (UserKind):

KindWhat it is
HUMANA person using the console
KIOSKA restricted account that only sees the kiosk apps assigned to it
BOTA service account for scripts, integrations and API tokens

Human and kiosk accounts are not created in your tenant. They come from the CoCoCo account service that people sign in through. The tenant API can only create BOT service accounts, and it refuses to create or change HUMAN and KIOSK accounts.

A kiosk account signs in the same way as any other user.

What a kiosk user sees ​

When a kiosk account signs in, the server delivers the kiosk shell instead of the console. The kiosk shell:

  • loads the apps assigned to the account (the getKioskModeInfo query);
  • opens the app directly if exactly one is assigned;
  • shows a grid to choose from if several are assigned, with a Back to apps link inside each app;
  • shows No Apps Available if none is assigned;
  • has a top bar with a menu containing Log out.

A kiosk account sees only the apps bound to it directly. Team bindings do not apply to kiosk accounts.

Build a kiosk app ​

A kiosk app is an ordinary custom app with the kind KIOSK. Everything in Custom apps and Server API applies: the same template, script, graphql(), graphqlMutation() and rpc().

Two things differ:

  • Identity. The app runs as the kiosk account. Its GraphQL calls and server API calls have exactly the IAM permissions of that account, so give the kiosk account a policy that allows what the app needs, and no more.
  • Server API sessions. A kiosk app's server API session is granted through the account's binding to the app rather than through the customapp:read permission.

Kiosk screens are often used by several people in turn, but the platform knows only the kiosk account, not the person in front of it. If your app needs to record who did something, ask for it in the app (for example a badge or operator number) and store it with the data.

Assign apps to a kiosk account ​

In the console, open the kiosk user's page and use the Kiosk App Allocations card. It lists only apps of kind KIOSK.

With the API, create a binding with attachCustomAppUser (requires the customappuser:write permission):

graphql
mutation AssignKioskApp($input: AttachCustomAppUserInput!) {
  attachCustomAppUser(input: $input) {
    customAppUser { id customAppId userId }
    errors { path message }
  }
}
json
{ "input": { "customAppId": "cap_...", "userId": "usr_..." } }

Remove it again with detachCustomAppUser, and list bindings with listCustomAppUsers:

graphql
query KioskBindings($appId: ID!) {
  listCustomAppUsers(first: 50, filter: { customAppId: { eq: $appId } }) {
    edges { node { id userId createdAt } }
  }
}

One account per station ​

To run different apps on different stations, give each station its own kiosk account and bind the right apps to each one. Locking the device itself (full-screen browser, auto-start, preventing other apps) is done with the tablet's or browser's own kiosk settings; CoCoCo does not manage the device.

Connect machines, automate workflows, and build custom apps for print production.