Signing in
The user chip in the title bar, the sign-in dialog and its PIN pad, switching and signing out, what a change of identity does to the open page, and how browsers and remote circuits sign in.
Signing in swaps the permissions in force on a screen from the Not signed in role to a user's role. It is never required: the station opens on the walk-up identity and stays usable there. There is one sign-in path with two doors, the user chip in the title bar and the Signed in now root of the Users page, and both open the same dialog over the same check. A browser that may not view at all gets a third surface, the view login, which is the same panel without the frame.
Signing in is not a station mutation. It stays available while the runtime is stopped by the free-mode limit, when every write to configuration is refused.
The user chip
The chip sits at the right of the title bar, after the theme keys and a divider, on every route and every connection. It shows a person glyph with a dot (green while signed in, grey otherwise) and the signed-in display name, or Sign in when nobody is. Pressing it opens the sign-in dialog. The chip never shows a role name: signed out it is a call to action, signed in it is a name.
The sign-in dialog
The dialog is titled Sign in, or Switch user while the roster shows and somebody is already signed in. While somebody is signed in its header reads "Signed in as " with a Sign out button. Esc or a click outside closes it without changing anything.
The roster
The roster is every local user of the station, in roster order, each row with a two-letter tag made of the initials, the display name, and one of two marks: a lock, "PIN required", or an enter arrow, "Signs in on tap". Tapping a user without a PIN signs in at once. Tapping a user with a PIN opens the PIN step. Every screen offers the same roster, whatever role is signed in on it.
When the roster is empty the dialog shows the reason instead of a blank list:
| Situation | Text |
|---|---|
| No local users yet | "This station has no local users yet. The first one, the primary administrator, is created on the Users page." |
| The published demonstration | "This is the published demonstration, so there is no account to sign in as. Everything here is view only." |
The PIN step
The PIN step shows the chosen user's tag and name, a Back button to the roster, the eyebrow Enter PIN, and the PIN pad: a readout that shows one dot per digit typed (never the digit itself) and, while empty, the accepted range; keys 1 to 9, a delete key, 0, and a confirm key that lights once 4 digits are in. The pad stops accepting at 6 digits. It is also a keyboard control: the pad takes focus when the step opens, digits append, Backspace deletes, Enter confirms. Clicking the readout gives the pad focus back without raising an on-screen keyboard.
A refusal stays on the step, under the pad, and clears the readout for the next try:
| Text | When |
|---|---|
| That PIN is not correct. | The PIN did not verify. |
| Too many wrong PINs. Try again in . | A browser circuit hit the wrong-PIN limit; the wait reads in seconds under a minute, in whole minutes above. |
| Sign-in failed. | A user without a PIN was refused (removed from the roster in between). |
While a sign-in is in flight the roster and the pad are inert, so a double tap cannot launch a second attempt.
Switching and signing out
Switch user is the same dialog opened over a signed-in screen: pick another user, and the identity changes with no sign-out in between. Sign out, in the dialog's header or on the Signed in now panel, returns the screen to the Not signed in role. On the station's own window it clears the station session; on a browser it clears only that connection.
Every outcome is reported in the connection's action feed, in the status bar:
| Outcome | Feed text |
|---|---|
| Signed in | Signed in as . |
| Refused, nobody signed in | Sign-in refused. Nobody is signed in. |
| Refused, somebody signed in | Sign-in refused. Still signed in as . |
| Locked out | Sign-in blocked after too many wrong PINs. Try again in . (followed by the same identity line) |
| Signed out | Signed out. or signed out. |
Every attempt also leaves a line in the Events console under the component Station access, naming the account and where the attempt came from ("the shell webview" for the station's own window, "a browser at " for a browser), so a shift's elevations can be read back later. A successful sign-in stamps the user's last access, which the roster shows.
Per-connection identity
The station's own window (the embedded webview that is the desktop shell) drives the station session: signing in there is signing in at the bench. Every browser, whether on a tablet across the network or on the station's own machine, carries its own operator: signing in there changes that browser alone, and it never inherits or changes who is signed in at the bench. The user chip, the Signed in now panel and every permission read on a screen answer for that screen's connection, so a remote viewer can never borrow the administrator sitting at the station.
The two paths differ in one more way. A browser's wrong PINs are counted, per account and per address: five in a row close the door for one minute, each further run of five doubles the wait up to fifteen minutes, and a run of failures that has been quiet for five minutes is forgotten. The station's own window has no counter, on purpose: whoever types at the bench is at the machine, and a lockout would be the one way a station could shut its own operator out.
What changes when the identity changes
Every surface reads the identity live, so a sign-in, a sign-out, a role edit or a user removal takes effect at once, on every connection it touches:
- The rail redraws with the entries the new role may open. If the page you are on belongs to an entry the new identity cannot see, the shell navigates to the first entry it can.
- Each page re-checks its own permission; a browser that reaches a route its role does not open gets the sign-in surface in place of the page.
- Every verb and field re-checks the role at the moment it is pressed, so a screen drawn under the old identity cannot act under it.
- A role edit on the Users page reaches every user holding the role, signed in or not; a user removed from the roster drops to the Not signed in role on every connection they held.
- Screens hidden from the new role by their Visible to checklist leave the View list, and an address typed for one falls back silently.
Browsers and remote access
A browser on the station's own machine is a loopback connection: it always views, on the Not signed in role until someone signs in on it. A browser on another device reaches the station only when Remote access is on, and then views only if its identity holds Remote access (LAN). That switch is off on the Not signed in role as shipped, so turning remote access on exposes nothing until a user with the permission signs in on the device, or the walk-up role is deliberately granted it for a kiosk or tablet.
A browser that may not view gets the view login instead of any page: the brand mark, "Ganter Lab", "Station", and the sign-in panel with no title bar or rail around it. The line above the roster names what was refused:
| Line | When |
|---|---|
| Sign in to view this station from the network. | A network connection whose identity lacks Remote access (LAN). With a user signed in there: "'s role has no remote access. Sign in as a user whose role grants it." |
| Sign in to open this page. | A connection that may view, on a route its role does not open. With a user signed in: "'s role does not open this page. Sign in as a user whose role does." With nobody: "Nobody is signed in here, and this page is not open to the Not signed in role. Sign in as a user whose role opens it." |
Signing out on a network device whose Not signed in role lacks Remote access (LAN) drops that device back to the view login. PINs travel over the network in clear text unless the station serves HTTPS, a Remote access setting.
What signing in does not do
- It does not stop, start or change the runtime, and it does not affect the embedded OPC UA server or an agent connected over MCP.
- It does not sign the station in to its Ganter account. That is the Account page and it belongs to the station, not to a user.
- It does not open anything the role does not hold. Elevation is exactly the role's switches; there is no temporary override and no per-user exception.
- It does not lock the station's own window after wrong PINs, and it never remembers a PIN.
- It cannot be attempted on the published demonstration, whose roster is empty by design.