Sign-in & roles
Two questions decide what a visitor can do in your app:
- Who are you? — answered by sign-in.
- What may you do here? — answered by the app itself: its access rules, its roles and its own list of people.
PhiWebs keeps these apart on purpose. Signing in proves who someone is; it never brings roles with it. A visitor gets only the roles your app gives them.
Sign-in: who the visitor is
Each app chooses how its visitors sign in, in the studio’s App panel under Sign-in & people:
| Choice | What visitors see |
|---|---|
| No sign-in | Every visitor is anonymous. |
| PhiWebs account | Visitors sign in with a PhiWebs account. |
| Company account | Visitors sign in with your organisation’s Microsoft Entra account, or another OpenID provider. |
The choice is saved in the project, in app/definitions/auth.json, so the
agent and the checks see it too. It reaches your visitors when you publish.
See Visitor sign-in for the setup steps.
Access rules: what each kind of visitor may do
The app’s access rules, also in app/definitions/auth.json, say who may do
what with each data model. A rule has three parts: who,
which model, and what.
Who is one of:
| Who | Means |
|---|---|
public | Every visitor, signed in or not. |
member | Every signed-in visitor. |
a role, such as staff | A signed-in visitor who holds that role in this app. |
What is one or more of: create, list, view, update, delete and
count, or the shortcuts read (list and view) and write (create, update
and delete). Adding own limits a rule to the records that visitor
created.
A booking app, for example:
| Who | Model | What | So that |
|---|---|---|---|
public | Booking | create | Anyone can book. |
member | Booking | read own | A signed-in visitor sees their own bookings. |
staff | Booking | read, update | Staff see and change all bookings. |
You don’t have to write these yourself: describe who should see what, and the agent writes the rules. Some rules worth knowing:
- A model no rule names is closed. The published app serves its records to nobody, and the studio’s Checks panel reports it as an error. The preview is more forgiving, so a page that works there can be empty once published if a rule is missing.
- Rules add up. A visitor may do something when any rule that applies to them allows it.
- A visitor who is not signed in owns nothing, so
ownrules only ever help signed-in visitors. - You, the owner, are not bound by the rules. You read and change the published app’s records in the studio, whatever the rules say.
Roles and the app’s people list
Roles are names the app declares in its access rules — staff, admin,
editor, whatever your app needs. Who holds which role is kept in the
app’s own people list, stored with the published app. There is no central
list: each app has its own.
Because the list belongs to the published app, it appears once you have published. You manage it in the App panel under Sign-in & people:
- Invite by e-mail. Add someone’s address and choose their role. They get the role when they sign in with that address — as long as their sign-in provider confirms the address is theirs.
- Who can come in. Either anyone who signs in, who then gets the default role you choose (or no role, as a plain signed-in member), or only people on the list.
- Change or remove anyone on the list.
By default, anyone who signs in may come in, with no role.
Only roles your app declares ever count. To add a new role, ask the agent to add it to the app’s access rules, then publish.
The first admin
An app’s people list starts empty. The first time you publish an app with an
empty list, you become its first admin: the person who publishes is added
with the app’s administration role — admin if the app declares it, otherwise
owner, otherwise staff, otherwise the first role the app declares.