The service desk kiosk

/portal. Needs portal.client.

A self-service kiosk where somebody identifies themselves and then chooses what they need. Put it on a tablet at the service desk with a card reader.

A kiosk is a device you reserve, not a browser you point at a URL. That is what lets you name a counter, say which campus it stands on, decide what that particular device offers, and revoke one iPad without un-enrolling the library.

Setting a device up

Two things, and they happen on two screens on purpose. A technician holds the tablet in one hand and their laptop in the other, and typing a staff password into a counter iPad is the exact shape of a phishing screen.

On your own machine: Admin, Features, Kiosks, then Reserve a device.

Label	What you call it: Front office iPad
Location	Free text, because a school’s idea of a place is not ours
Campus	Which site it stands on
Card tap	Whether this device offers the reader. On by default
Password entry	Whether the username and password form appears at all. On by default
Refuse other campuses	Off by default. See below
Visitor sign-in	Off by default. Also makes the device the visitor and contractor sign-in point. See visitor sign-in
Idle timeout	Seconds of no interaction before the session ends. 90 by default
Session ceiling	Seconds a session lasts regardless of activity. 300 by default

You get a six-digit code. It is single use and good for ten minutes.

On the tablet: go to /portal/kiosk and type the code.

The address is printed beside the code in Admin, so you read both off one screen. The device is then enrolled and holds its own secret; nothing about a staff account is ever left on it.

That page also answers “what is this device?”. It asks the server rather than trusting what the browser is holding, so a tablet still carrying a secret for a kiosk you have since revoked is told so, in front of the person who can fix it.

There is deliberately no “unlink this device” button. Forgetting the secret locally would leave the record looking live in Admin with nothing answering to it. Pointing a device somewhere else takes a fresh code: press New code next to the kiosk in Admin, which is also what un-enrols whatever held the old one.

Revoking one

Admin, Features, Kiosks lists what is enrolled, where, and when each was last seen. Revoking one ends its live session as well as refusing the next, so an iPad that walks off the counter stops working immediately and every other counter keeps going.

If a kiosk stops being one

A kiosk keeps its secret in the browser’s own storage, so clearing the browser’s data, resetting the tablet, or re-imaging it through your MDM takes the secret with it. The device still opens the portal — it just opens it as an ordinary browser, which means the password form comes back, the campus restriction stops applying and the short session limit reverts to the general one. It looks fine from the front.

The audit log now says when this happens: a device presenting a kiosk credential that matches no kiosk writes a line naming the address it came from. If you see those, the device at that address needs a fresh setup code. It is also worth checking Admin, Features, Kiosks — a kiosk whose last seen has stopped moving is the same story from the other side.

If you already use the shared key

Earlier versions enrolled kiosks with one key for the whole school, carried to the device as ?kiosk=…. It still works for a school that has not reserved a device yet, so nothing goes dark on upgrade.

Claiming your first device switches the shared key off for the whole school, and any remaining old-style device stops tapping at that moment. That is the price of revocation meaning anything. Do the rollout in one sitting rather than across a week, and have every counter in front of you before you start.

Signing in

Tap a card on a connected reader, where this kiosk offers card tap. The kiosk recognises it, flashes a verified ID card, and greets the person by name.

Or type a username, where this kiosk offers the password form.

A kiosk with password entry switched off leads with the reader and says “Card not working? Please see the office.” That is enforced at the server, not just hidden on the page, because a setting enforced only in the interface is enforced by whoever has not opened developer tools.

Card tap only ever works on an enrolled kiosk. A card is one factor, and a found card plus any laptop must not open a student’s portal.

About username entry

Typing a username proves nothing, so it is disabled by default in production across the whole deployment. People tap their card instead.

If your kiosk sits somewhere physically supervised and you want username entry, an administrator can enable it with PORTAL_USERNAME_ENTRY=1. Each kiosk’s own password entry setting then decides which counters offer it.

Refusing other campuses

A kiosk pinned to a campus can refuse to open a session for somebody belonging to a different one. An iPad in the junior school office is not a place the senior school’s records should appear.

Off by default. It is settable through the API today; the checkbox belongs with a campus picker and is not on the admin screen yet.

Ending a session

Four ways, and each covers something the others miss.

	Default	Covers
Idle timeout	90 seconds	The student walked away
Session ceiling	300 seconds	Somebody parked on the page, or a token lifted off the device
Finish	Immediate	The student is done and says so
The next card tap	Immediate	The queue moved on

Twenty seconds before the idle timeout the kiosk asks “Still there?” with a countdown and a Stay signed in button. That warning matters: a student typing a long repair description with a stylus generates no events for a minute, and a kiosk that dumps their form without warning is a kiosk the school turns off.

A tap while somebody is still signed in switches user rather than being ignored. At a counter the next student taps while the last one’s menu is up, and the alternative is that they read the previous student’s screen while waiting.

Signing out is real. The session is ended on the server, not merely forgotten by the tab, so a copied token dies with it. The screen is cleared before anything is waited on, and every form on it is reset, so the next person starts on an empty form rather than on the last one’s half-written repair reason.

Both timers are bounded server-side. Idle is clamped between 15 and 900 seconds, and the ceiling between 30 seconds and an hour, so a typo cannot produce a kiosk that never signs anybody out. 0 for the idle timeout is honoured as “no idle timeout”, which a kiosk in a locked room may want, and the ceiling still applies, so it switches off one clock rather than both.

Legacy shared-key and demo kiosks use a 120-second idle timeout and a 900-second session ceiling. These fallback values differ from a reserved device’s default 90/300-second settings. Repair progress is shown inside the current sitting; signing out clears it without placing a reusable tracking link in browser history.

What people can do

Book a repair

1. Pick the device. The kiosk lists devices already linked to them. If theirs is not listed, they choose “My device is not listed” and type the serial.
2. Choose a repair type. Each shows its coverage, so they know before handing the device over whether this is likely to cost anything.
3. Describe what happened.
4. Tick “I need a loan device” if they want a loaner.
5. Lodge.

They are told the outcome immediately, including the loan number if one was assigned, and that they will be emailed when it is ready. The confirmation then counts down back to the tap screen.

At the desk, the submission arrives with a sticky toast so it is not missed.

My submissions

Their repairs with current status, so they can check progress without asking anybody.

Get assistance

Two kinds of request.

Password reset. The fastest path is self-verification: the person taps their own card, or types its number, and goes straight to a “set a new password” screen. No staff time at all.

If they cannot, they choose “Request reset (staff verifies)” and an ICT staff member approves it at the desk. The kiosk shows a waiting spinner and updates automatically when approved or denied.

Something else. They describe what they need and a staff member verifies their identity and helps.

Password resets go through your LDAP connector and are subject to your directory’s password policy, so a password your directory rejects is rejected here with the directory’s own message.

Purchase

Buy a consumable: a bag, an adapter, a cable.

Products appear as tiles with their photo or icon, name, description and price, so the right one can be picked at a glance.

1. Pick the product and quantity.
2. Verify it is them by tapping or entering a card, or entering a password.
3. Confirm.

A confirmation is emailed to the student’s parents. That message cannot be switched off, because a parent is owed a receipt for money taken.

Help and guides

Opens the help centre.

Visitor sign-in

From 0.21.0, with Facilities on (the campus operations add-on). A reserved kiosk with Also the visitor and contractor sign-in point (/visit) ticked, under Admin, Features, Kiosks, becomes the front-office sign-in book for the visitor register. It is off by default on every device, and switching it on changes nothing about what the same device does at /portal.

Enrol the device as above, then open /visit on it. A device that is not reserved, or does not have visitor sign-in on, says so and points a staff member at the setup steps. It keeps its secret either way.

Signing in. The visitor chooses Visitor or Contractor and gives their name, company and, optionally, a phone number, then who they are here to see and why. The host list is a typeahead over staff on the roster at the kiosk’s campus, and staff with no campus: it needs two letters, shows at most eight names, and shows nothing else about them. A contractor the office has issued a card to can tap it instead of typing. They are told to wait at the front office to be collected, or, for a contractor whose WWCC is expired or not recorded, that a staff member needs to see them before they go in.

Signing out. Tap the card, or type the full name. The name must match exactly one person signed in at this campus, ignoring case; anything else asks them to see the front office.

The kiosk never lists who is on site. A list of the strangers in the building is not something to leave on a counter; the on-site list is on the desk, for staff with visitor.view. The kiosk cannot record a WWCC either, and every screen clears itself after 90 seconds.

A visitor kiosk signs people in and out at the campus it is reserved for, so reserve one per front office. If your school still uses the shared kiosk key, claiming the first device switches it off; plan that before you set up a visitor kiosk.

Setting it up physically

The arrangement that works:

• A tablet on a stand, at the counter, in full screen, showing /portal.
• A USB card reader attached. Most act as keyboards and need no configuration. The kiosk keeps a hidden field focused while it is waiting for a card, so the reader always has somewhere to type, including on an iPad, where nothing would be focused otherwise. The on-screen keyboard stays down, and focus is handed back the moment somebody uses a real field.
• A sign saying what it is for. “Book a repair here” gets used; an unlabelled tablet does not.
• Somewhere staff can see it, both so people get help if they are stuck and because that supervision is what makes username entry defensible if you enable it.

The kiosk shows its own name discreetly in the header, so a student can tell they are on a school device and a technician can tell which record they are looking at without opening Admin.

What it changes

A kiosk absorbs three categories of desk traffic: booking repairs, checking status, and password resets. Between them that is most of the queue at a school ICT counter.

Point the self-verified password reset out to your team. It handles the most common request in any school without a staff member.

Configuration

Setting	Effect
Per kiosk, in Admin	Card tap, password entry, campus enforcement, visitor sign-in, idle timeout, session ceiling
PORTAL_USERNAME_ENTRY	1 allows username-only entry on this deployment. Off by default
PORTAL_SESSION_TTL_MS	The default portal session lifetime, 15 minutes. A kiosk session takes the shorter of this and its own ceiling

Reserving and revoking kiosks needs feature.manage, the same permission that turns the portal module on. There is no school that wants one person deciding the portal exists and another deciding which counters it taps at.

Repair types and their coverage come from workflow. Loan assignment comes from loan groups. Products come from stock.

Not yet

The induction kiosk and the card checker still have their own notion of a kiosk. Induction signs in with a device secret, but neither reads that device’s settings.