USB kiosk: take and return a drive without a ShopDB login
The people who actually take USB drives are standing at the cabinet, and most of them have no account here. Check-out and check-in were gated behind a login that was not doing much anyway: both modes already attribute the action to a scanned BADGE rather than to the signed-in user, so the login was gating the screen, not the record. /usb-kiosk is a full-screen touch page modelled on the parts kiosk, off unless a site sets usb_kiosk_enabled - every route 404s until then, rather than 403, so a disabled kiosk does not advertise that there is a door here. It works against the self-hosted tables or an existing cmmc_usb database. THE LIST IS THE TRADE. These drives carry no barcode, so unlike the parts kiosk there is nothing to present and the screen has to offer a list - which exposes more than a scan-first design, where you had to already hold a drive to learn anything. So the list is not anonymous: an SSO comes first and must resolve to a real person before any drive is named, which is the same bar taking a drive already had to clear. It is a POST so the badge stays out of proxy access logs. The main screen shows the caller's own drives, what is free, and a COUNT of everything else; holders of other people's drives appear only behind a second deliberate tap, so nobody reads the whole cabinet off a wall panel in passing. A badge that resolves to no employee is REFUSED, unlike the signed-in route which creates the user row. A checkout nobody can trace to a person defeats the tracking, and at a kiosk there is no operator standing there to vouch for it. Returning somebody else's drive asks first and then records the badge that was SCANNED, so the log says who actually handed it back. That is the honest record and it needs no change to a schema this app does not own. Refusing a mismatch outright is a setting but not the default: a drive left behind by somebody on leave would otherwise be unreturnable at the kiosk, which just moves the problem to a person with a login. The authz sweep caught these writes, twice - once for the two mutations and again for the two list endpoints. Both are exempted with the reasoning written out beside the parts-kiosk entry rather than silenced. The list endpoints are POSTs that change nothing. Verified by driving the real page: SSO on the keypad, tap Take, database moves.
This commit is contained in:
@@ -51,6 +51,30 @@ EXEMPT_ENDPOINTS = {'knowledgebase.track_click', 'users.update_user',
|
||||
# docs/proposals/printedparts-plugin.md; justification in
|
||||
# the plugin README.
|
||||
'printedparts.kiosk_take',
|
||||
# Deliberately open kiosk writes, same bar as the parts
|
||||
# kiosk: they can ONLY move a USB device between
|
||||
# checked-out and checked-in, and only when a site has set
|
||||
# usb_kiosk_enabled (off by default - every one of these is
|
||||
# a 404 until then). Identity is a scanned badge resolved
|
||||
# server-side, and a badge that resolves to no employee is
|
||||
# refused rather than recorded, so nothing here can create
|
||||
# an untraceable checkout. The people who take drives stand
|
||||
# at the cabinet and mostly have no account, and both modes
|
||||
# already attributed the action to the badge rather than to
|
||||
# the signed-in user - the login was gating the screen, not
|
||||
# the record. Covered by tests/test_plugins/test_usb_kiosk.py.
|
||||
'usb.kiosk_checkout',
|
||||
'usb.kiosk_checkin',
|
||||
# The kiosk's two list endpoints. POSTs that CHANGE NOTHING:
|
||||
# they are reads, shaped as POSTs so the badge stays out of
|
||||
# query strings and proxy access logs. Same gate as the
|
||||
# writes above - 404 unless usb_kiosk_enabled, and they name
|
||||
# no drive until the badge resolves to a real person. The
|
||||
# drives have no barcode, so a list is the only way to pick
|
||||
# one; kiosk_others additionally 404s when returning for
|
||||
# somebody else is switched off.
|
||||
'usb.kiosk_session',
|
||||
'usb.kiosk_others',
|
||||
# Redeeming a shared secret. The recipient usually has no
|
||||
# account here, so the unguessable 128-bit token IS the
|
||||
# authorisation - gating this on a role would make the
|
||||
|
||||
Reference in New Issue
Block a user