Files
shopdb-flask/plugins/usb
cproudlock 7ac1ee3077 Refuse a kiosk caller wearing an address that belongs to the path
Both kiosks admit a check-in or check-out with no login when the caller sits in
a configured network. The subtraction that makes that safe was missing.

A reverse proxy normally sits ON the plant network a site enters in the
allowlist. When the proxy forwards nothing - misconfigured, or something
bypassed it - the request arrives wearing the proxy's own address, which matches
the allowlist, while carrying no evidence whatever about who sent it. That is
the one case that has to refuse, and it was being admitted. The previous
fail-closed test only looked closed because the proxy in it happened to sit
outside the range.

Addresses that belong to the path are now subtracted before the allowlist is
consulted: loopback always, since no site's kiosk is the server itself, plus
whatever the site declares as its proxies. USB and printedparts get the same
treatment - they had diverged for no reason anybody chose.

Three more, same surface:

A range that admits everybody can no longer be saved by accident. 0.0.0.0/0 and
::/0 are refused outright, anything wider than a site plausibly needs is refused
unless an explicit override is set, and the refusal says why.

The kiosk token no longer travels in a URL. The provisioning link carries a
single-use setup code redeemed on first open, so the token stays out of browser
history, referrers and proxy logs. The route is declared public deliberately:
the secret is the code, the way a password-reset link is the secret.

The badge-to-name lookup is bounded. It answers without a login and is now
reachable from a whole network rather than one screen, so a source that keeps
missing gets refused rather than being allowed to walk the directory. On by
default, budget and kill switch are settings.

All four new settings carry controls on their settings pages. A setting that can
stop the kiosk, or widen it, must not be reachable only by hand-editing rows.

The installer's client-IP advice is corrected: it described the opposite of what
the shipped waitress flags do, and named only GE-Enforce as the thing that
breaks when the rule is absent, when the two kiosk allowlists depend on it too.
2026-09-18 13:30:24 -04:00
..

USB plugin - CMMC USB check-in/out database contract

The USB plugin tracks removable-media check-in/out for CMMC compliance. Device and log state live in a separate, read-write MySQL database (cmmc_usb), reached with parameterized pymysql via cmmc_usb_connection(). Names of people are resolved from the HR employee directory (see the employees plugin).

The plugin's own reference tables (usbdevicetypes, usbdevices, usbcheckouts) live in the main app database; only the live check-in/out data is in cmmc_usb.

The schema is standardized across sites - the cmmc_usb check-in/out solution is the same deployment everywhere, so the tables below match as-is and no schema adaptation is needed. The database name may differ per site, though - set cmmc_usb_db_name (default cmmc_usb) to match the local name. The view recipe at the end is only a fallback for a site that somehow differs. (Contrast the employee directory, which genuinely varies per site.)

Connection

Credentials resolve settings-first, then environment, except the password which is env-only (never stored in the app database).

Field Setting key (editable in the setup wizard) Env var (fallback)
Host cmmc_usb_db_host CMMC_USB_DB_HOST
Database cmmc_usb_db_name CMMC_USB_DB_NAME
User cmmc_usb_db_user CMMC_USB_DB_USER
Password (not stored) CMMC_USB_DB_PASSWORD

Set the password in .env; the setup wizard's Features step shows the exact line to paste. This database is read-write - the app account needs SELECT, INSERT, UPDATE. Engine is MySQL/MariaDB (pymysql).

Required schema

The plugin runs raw SQL against these tables (or views - see below).

devices

Column Type Notes
device_id VARCHAR Primary key; the device serial/tag
device_desc VARCHAR Description
device_owner VARCHAR Owner
status VARCHAR Check-in/out state
locker_location VARCHAR Where the device is stored

Operations: SELECT (list + by id), INSERT (register device), UPDATE (edit fields, change status).

checkinoutlog

Column Type Notes
log_id INT (PK) Auto id
badge_number VARCHAR Person's badge
device_id VARCHAR FK to devices.device_id
action VARCHAR check-in / check-out
timestamp DATETIME When it happened
scanned_viruses (text/int) Scan result
locker_location VARCHAR Locker at time of event
sanitized (bool/int) Sanitization flag

Operations: SELECT (history per device), INSERT (log an event).

users

Column Type Notes
badge_number VARCHAR Primary key; the scanned badge
first_name VARCHAR Given name
last_name VARCHAR Surname

Operations: SELECT by badge, INSERT (auto-add a badge on first scan).

Employee directory dependency

To turn a scanned badge into a name, the plugin also reads the HR employees directory (via the employees plugin's connection). A badge shaped 0<digits>BZ carries a PayNo (the digits); lookups try employees.SSO and employees.PayNo. See plugins/employees/README.md for that schema and connection.

Sites whose USB-tracking database uses different table/column names should create read-only/updatable views named devices, checkinoutlog, and users that map local columns to the names above. Example:

CREATE VIEW devices AS
SELECT
  asset_tag     AS device_id,
  description   AS device_desc,
  owner         AS device_owner,
  state         AS status,
  storage_bay   AS locker_location
FROM usb_assets;

Because the plugin writes to devices/checkinoutlog/users, either make the views updatable (single-table views usually are) or expose real tables with these column names. Grant the app account SELECT, INSERT, UPDATE.

Notes:

  • device_id and badge_number are the natural keys the plugin matches on.
  • If cmmc_usb is unreachable, USB endpoints return an error and the rest of the app keeps working (the feature degrades, it does not crash the app).