From 405a2ef919c04f13bb1de7d765e5fd896d0044d1 Mon Sep 17 00:00:00 2001 From: cproudlock Date: Thu, 3 Sep 2026 08:38:20 -0400 Subject: [PATCH] Cap request bodies, close a hole in the gate, fix to_dict and two settings pages Six fixes that were ours regardless of what the sister site does. Four came out of our own reviews; two you reported from the settings pages. MAX_CONTENT_LENGTH was set nowhere. Every upload route caps its own payload, but each of those checks runs after the body has arrived: the first touch of request.form or request.files makes Werkzeug parse the whole multipart and spool the file to a temp file, so a route can reject the content and still have paid for the transfer and the disk. Three separate reviews found that shape in three different routes, which makes it a property of the app rather than of any handler. 128 MB, clearing the 64 MB agent binary with room for the envelope. The naming gate excluded devnotes with --exclude-dir, which matches a directory of that NAME at any depth - so a force-added plugins//devnotes/ was invisible to every check in the file, ADR-015 included. Replaced with a path anchored post-filter. Verified by planting the same site literal in root devnotes/ AND in plugins/endpoints/devnotes/: the gate now reports exactly one, the nested one. Before, it reported none. BaseModel.to_dict walked __table__.columns and published every one, so a model without an override published whatever it carried - including columns added later by someone not thinking about this method. User has no override, so User.to_dict() returned its bcrypt hash. Nothing calls it in a response path today, which is luck rather than design. A blanket allowlist would empty the output of all 34 models relying on the default, so this pins a floor instead: named secret-bearing columns are never emitted, and a model may extend the set. Eight tests, including a sweep over every mapped model. ActionPicker's Esc handlers had .prevent but not .stop, so the event bubbled to the wrapper and closed the whole picker instead of returning to the monitor list. The branding page reported "error loading image" on the site and badge logos. Two bugs stacked. The load failure was real: the preview used the stored value as a raw src, and that value is root-relative, so under /shopdb or /ops it resolved against the SERVER root and 404d - siteSettings.js wraps every logo in withBase() and this page was the one place that did not. With that fixed two of three were still invisible, because the shipped GE mark is fill="white" for the dark sidebar and was rendering white-on-white. The preview tile now sits on a mid-tone checker so artwork of any colour reads against it. The floor-map levels table ran off the right with its cells crushed - nine columns of inputs, no scroll wrapper, and .data-table is styled nowhere. My first attempt reached for the global .table-container and made it WORSE: that class also sets white-space: nowrap, and a full sentence of hint text lives in one of the cells, so nowrap forced the table wider still. It now scrolls in a local wrapper, the hint wraps, and the name input has a width instead of collapsing to one character. Suite 2377, frontend 324, gate green. Scope: product --- frontend/src/assets/style.css | 24 ++++++- .../src/views/settings/BrandingSettings.vue | 8 ++- .../src/views/settings/FloorMapSettings.vue | 22 +++++- .../computers/frontend/views/ActionPicker.vue | 4 +- scripts/check-naming-and-style.sh | 24 ++++--- shopdb/config.py | 16 +++++ shopdb/core/models/base.py | 29 +++++++- tests/test_core/test_to_dict_floor.py | 69 +++++++++++++++++++ 8 files changed, 180 insertions(+), 16 deletions(-) create mode 100644 tests/test_core/test_to_dict_floor.py diff --git a/frontend/src/assets/style.css b/frontend/src/assets/style.css index 18bd2c44..30b8d035 100644 --- a/frontend/src/assets/style.css +++ b/frontend/src/assets/style.css @@ -1323,13 +1323,33 @@ td.actions .btn + .btn { gap: 0.75rem; margin-top: 0.4rem; } +/* A branding preview has to show a logo whose colour we do not control. The + shipped GE mark is fill="white" because it lives on the dark sidebar, so on a + plain white tile it rendered white-on-white and read as a failed load. A + checker ground makes any logo visible - light, dark or transparent - and is + the usual convention for previewing artwork with alpha. */ .map-thumb { height: 40px; + min-width: 40px; border: 1px solid var(--border); border-radius: 4px; - background: #fff; + /* MID-TONE, not white and not near-white. The tile has to show artwork whose + colour we do not control: the shipped GE mark is fill="white" for the dark + sidebar, the monogram is fill="black". A light ground hides the first, a + dark ground hides the second, so the checker sits either side of mid grey + and both read against it. */ + background-color: #9aa1ad; + background-image: + linear-gradient(45deg, #6f7783 25%, transparent 25%, transparent 75%, #6f7783 75%), + linear-gradient(45deg, #6f7783 25%, transparent 25%, transparent 75%, #6f7783 75%); + background-size: 12px 12px; + background-position: 0 0, 6px 6px; + padding: 2px; +} +.map-thumb-dark { + background-color: #222; + background-image: none; } -.map-thumb-dark { background: #222; } .settings-success { margin-top: 1rem; padding: 0.75rem; diff --git a/frontend/src/views/settings/BrandingSettings.vue b/frontend/src/views/settings/BrandingSettings.vue index bf455bc2..dcb6294b 100644 --- a/frontend/src/views/settings/BrandingSettings.vue +++ b/frontend/src/views/settings/BrandingSettings.vue @@ -24,7 +24,7 @@ >
- +
{{ logo.hint }} @@ -132,6 +132,12 @@