Pages and packs

How is a page built and released, and whose access does it use?

Each page is code, usually kept in a pack: one folder that can hold a page with its own tables and tools. An administrator releases it by rebuilding the Web App, and it then runs with the permissions of whoever is signed in. Keep in mind: Other code a pack adds can run with the module's own authority. A public web address a module defines answers anyone, and its code can reach more than the caller could. A page marked public also opens for signed-out visitors. They have no session, so they see only what its code holds or data it pulls from addresses that need no sign-in.

Every module has its own Web App, the app people use in a web browser. The module can add pages of its own to that Web App. Each page is shown as a tab along the top to the people allowed to open it. Keep in mind: A page can also keep its own web address without showing a tab. Pages are written as code. There is no point-and-click page builder.

An administrator usually builds a page as a pack. A pack is one folder inside the module. It holds the page, the tables that store its data, any tools it adds, and its own notes. Keep in mind: A pack stays within its module unless its administrator later chooses to publish it. Pack code is trusted. It runs with your module's authority or the signed-in person's access, so install packs from others only from sources you trust.

An administrator decides whether each page is for administrators only, for every signed-in member, or public. A public page opens without sign-in. It shows signed-out visitors only that page and a Sign in button. Keep in mind: There is no switch in Settings. The choice is written into the page and takes effect only when the Web App is rebuilt. No page is public out of the box. Each module decides for its own Web App.

Anyone allowed to edit a page's files can change it. Nothing reaches people until an administrator rebuilds the module's Web App. A failed rebuild names the reason and leaves the previous version running. Keep in mind: Applying a pack's changes rebuilds the Web App as part of that step. The administrator should review a change before rebuilding, especially one that makes a page public.

When a page reads or saves data directly, it acts as the signed-in person. The module's permissions, not the page, then decide what that person may see or change. Keep in mind: Hiding a button only changes what people see. Permissions protect the data. Tools and open web addresses a module adds can act with the module's own authority, so review what each one can return or change.

A public page cannot directly read the module's records, files, accounts or bot conversations. It can show module data only through a door the module chooses to open. That door is either a web address that answers anyone, or the module's own sign-up. Keep in mind: Neither door exists unless the module adds it. Whatever such an address returns is visible to anyone. A self-registered account passes every check that only asks whether someone is signed in, so review every permission before allowing sign-up.

Anything written into any page, public or not, can be read by anyone who can reach the web address. Private text, names or keys must therefore never go into a page. Keep in mind: Sign-in protects the module's stored data, not what is written into a page itself.