Stations
Setting Up a Station
Create station templates and register kiosk devices.
Setting up a station has two parts: defining a Station Template (what the station can do), and registering the physical Station itself (which device, and which template it uses). Both are managed under the Resources section of the sidebar.
Step 1: Create a Station Template
Open Station Templates under Resources, then select Add Template (or edit an existing one).
| Field | Description |
|---|---|
| Name | A name describing this set of capabilities, e.g., “Lab Kiosk (Full Access” or “Lobby Display) View Only”. |
| Description | Optional notes about where/how this template is used. |
| Station type | What kind of screen this is; see below. |
| Capabilities | The specific actions this station allows; see below. |
Station type
Pick the type first. It decides what a station using this template actually displays, and it bounds the capability list underneath. See Station types for what each one is.
Changing the type re-checks the capabilities immediately:
- Capabilities the new type requires are ticked and locked.
- Capabilities it does not allow are greyed out and dropped from the selection.
- If the type is a display, the identification toggles disappear: a screen nobody stands at cannot ask anyone who they are.
You can switch types while editing to compare them; nothing is saved until you select Save Changes, and your original selection comes back if you switch back.
Capabilities
Capabilities are grouped by area:
Print Jobs: View, Upload, Approve, Reject, Cancel, Prioritize, Deprioritize, Reprint, Confirm Outcome
Printers: View, Clear, Dismiss Errors, Pause, Resume, Stop
Materials: View
Enable only the capabilities this station needs. For example, a kiosk meant only for checking on prints might enable just “Print Jobs: View” and “Printers: View”, while a full-service lab kiosk might enable everything.
Which capabilities you can pick from depends on the station type: a capability outside the type’s allowance is greyed out, and one the type requires is ticked and cannot be removed.
Requiring identification per capability
Next to each enabled capability is a shield icon: toggle it to require identification (PIN or card) before that action can be performed at the station. This lets you mix anonymous and identified actions on the same station, for example:
- Printers: View: open to anyone walking up (no identification)
- Printers: Pause: requires identification, so it’s clear who paused a print
- Printers: Stop: requires identification; stopping a print scraps the part, so it’s worth knowing who did it and why
- Print Jobs: Approve: requires identification, since approvals are tied to a person
Step 2: Register the station device
Open Stations under Resources, then select Add Station (or edit an existing one).
| Field | Description |
|---|---|
| Name | A friendly name, e.g., “Lab Kiosk 1” or “Front Desk Tablet”. |
| Identified by | How Pluraprint recognises this screen: IP address or Client certificate. |
| IP Address | The IPv4 address of the device, when identifying by address. |
| Client certificate | The device’s certificate, when identifying by certificate. |
| Enabled | Turn off to immediately block this device without removing its registration. |
| Template | The Station Template that defines this station’s capabilities. Choose “No template” for a station with no special capabilities. |
| Site | Where this screen physically is. Optional, but see below. |
Setting the site
The template says what a station can do; the site says where it is. They are different questions, and a pickup screen needs both.
A pickup station shows the prints on the shelves it can reach, and “the shelves it can reach” means every bin assigned to its site. Leave the site unset and there are no such shelves, so:
- The collection board is empty.
- Start a check refuses, saying the station has not been told which site it is at.
Set it and both start working immediately. See Shelving that several sites use for how one rack can serve several sites.
The site does not narrow what else a station shows. Its printer grid, queue, approvals and history cover the whole deployment however the site is set, and they update live the same way, including on a station with no site at all. Pickup is the one place the site decides what appears, because shelves are physical.
Changes reach the screen straight away
Renaming a station, moving it to another site, switching its template, or turning it off takes effect on the screen itself within a second: no reload, no walking over to it. The same is true of editing a Station Template: every station using it picks up the new capabilities immediately, so a tab you have just removed stops being offered and one you have just added appears.
A station is only ever matched by the mechanism it is registered with. A station set to Client certificate is not reachable by IP address even if it also has one, and vice versa, so moving a kiosk to certificates genuinely closes the address as a way in, rather than adding a second door.
Registering a station by IP address
Enter the device’s IPv4 address. The device must connect from exactly that address.
We recommend giving address-identified station devices a static IP (or a DHCP reservation) so they don’t need to be re-registered after a restart.
Registering a station by client certificate
Client certificates are the stronger option, and the right one for any station that can act on other people’s work. They take a little more setup, in two places.
Your administrator configures the server once. Pluraprint does not terminate TLS itself,
so whatever sits in front of it: Cloudflare, an ingress controller, your own reverse proxy,
is what requests and verifies client certificates. Once it does, it forwards the verified
certificate to Pluraprint in a header, and Pluraprint is told which header that is by setting
STATION_CLIENT_CERT_HEADER in .env:
# Cloudflare, with client certificate forwarding enabled on the zone
STATION_CLIENT_CERT_HEADER=cf-client-cert-der-base64
# nginx terminating TLS itself, with `proxy_set_header X-SSL-Client-Cert $ssl_client_escaped_cert;`
STATION_CLIENT_CERT_HEADER=x-ssl-client-cert
That one value is read by both the api and web containers, which is why it belongs in
.env rather than on a single service. Three things follow from setting it:
- The bundled nginx stops stripping that header, and keeps stripping every other one. Left to itself nginx forwards any header a client sends, so by default it deletes every known client-certificate header before the API can see it. Naming one is how you say your own ingress controls it.
- The API believes the header only from a trusted proxy. A request that reaches the API
without coming through a proxy in
TRUSTED_PROXY_CIDRShas its certificate header ignored regardless. - Your terminator must overwrite the header on every request, so a client cannot supply
its own. Cloudflare does this for its
Cf-headers automatically; nginx does it whenever the header is set from$ssl_client_escaped_cert.
If your terminator also reports whether the certificate verified (nginx’s
$ssl_client_verify, for example), name that header in STATION_CLIENT_CERT_VERIFY_HEADER
and Pluraprint will refuse any certificate it says did not verify. It is only consulted when
the header is actually present, so a terminator that rejects unverified clients outright
needs no extra configuration.
Until STATION_CLIENT_CERT_HEADER is set, the Client certificate option in the station
form is disabled and says so.
Then register each device. Issue the device a client certificate from your own certificate authority, install it in the browser or the operating system’s certificate store, and paste the certificate into the station’s Client certificate field. Pluraprint records its SHA-256 fingerprint and subject; the certificate itself is not stored. If you only have the fingerprint to hand, you can paste that instead.
The quickest way to get the right value is to open the kiosk URL on the device first: an unregistered station that presented a certificate shows its fingerprint and subject on screen, ready to be handed to whoever is registering it.
Step 3: Open the kiosk
On the station device, open a browser to your Pluraprint URL with the /station/ path (for
example, https://print.yourcompany.com/station/). If the device matches a registered,
enabled station, the kiosk loads automatically: there’s no separate sign-in step for the
device itself.
If you see “This station is not registered in the system,” the screen shows exactly what Pluraprint saw: the device’s IP address, and its client certificate’s fingerprint and subject if it presented one. Check those against what you registered in Step 2. A device that presented no certificate on a deployment expecting one is told so directly, which is usually a certificate that was never installed in the browser’s own store.
Step 4: Connect a card reader (optional)
To let people identify themselves with a card or fob, install Pluraprint Desktop on the same Windows or macOS device that runs the station. Download the installer for your platform from the Pluraprint release provided by your administrator, connect the USB serial reader, and open Pluraprint Desktop.
In Settings, leave Serial port set to Auto-detect unless your device has more than one compatible reader. Start the scanner and confirm that the status is Connected. The station connects to the desktop service on the same device automatically; card data is not exposed to other computers on the network.
Managing templates and stations
- The Station Templates list shows each template’s name, number of capabilities, and how many stations use it. A template in use by one or more stations can’t be deleted, reassign those stations first.
- The Stations list shows each station’s name, how it is identified (its address, or its certificate’s subject), assigned template, status (Enabled/Disabled), and when it was created.
Once your station is set up, see Using a Station for what people will see at the kiosk.