@7365admin1/core 3.48.1-staging.180 → 3.48.1-staging.181

package/.changeset/hid-configuration-write-allowlist.md

@@ -0,0 +1,22 @@
+---
+"@7365admin1/core": patch
+---
+
+Constrain what a HID configuration write may contain, and stop storing password salts
+
+`PUT /readers/:readerId/configuration` is a passthrough to the reader's
+`set_configuration.fcgi`, and its body schema was `Joi.object().unknown(true)`.
+That reaches `monitor.hostname`, `monitor.port` and `monitor.path` — the block
+that decides which server receives every identification at that door — so one
+request could redirect a reader's entire event stream. Writes are now limited to
+the two modules the product actually writes, `pjsip` and `identifier`, which are
+the only two `setReaderConfiguration` call sites in `layer-common`. Module
+contents stay unvalidated (the vendor owns those keys), reading configuration is
+unchanged, and the monitor block is still managed by the server through
+`setReaderMonitor` and `configureReaderIntegration`, which do not use this
+schema.
+
+`sanitizeHidPayload` — the central redaction every `addEvent` already passes
+through — did not include `salt`, so a password salt was still being persisted
+beside the hash it belongs to. `salt`, `salt_value` and `saltvalue` are now
+redacted like the rest. This does not touch records already stored.

package/dist/index.d.ts

@@ -10659,6 +10659,21 @@ declare const schemaUpdateHidSitePermissions: Joi.ObjectSchema<any>;
 declare const schemaHidAmicoExecuteActions: Joi.ObjectSchema<any>;
 declare const schemaHidAmicoIntercomCall: Joi.ObjectSchema<any>;
 declare const schemaHidAmicoConfiguration: Joi.ObjectSchema<any>;
+/**
+ * A configuration WRITE is a passthrough to `set_configuration.fcgi`, so an
+ * unrestricted body reaches `monitor.hostname`, `monitor.port` and
+ * `monitor.path` - the block that decides which server receives every
+ * identification at that door. A single request could redirect a reader's
+ * entire event stream.
+ *
+ * Writes are limited to the two modules the product actually writes, which are
+ * the only two `setReaderConfiguration` call sites in `layer-common`:
+ * `pjsip` (HidIntercomManagement.vue) and `identifier`
+ * (HidQrCodeConfiguration.vue). Module CONTENTS stay unvalidated - the vendor
+ * owns those keys - and READING configuration is unchanged. The monitor block
+ * is still managed by the server through `setReaderMonitor` and
+ * `configureReaderIntegration`, which do not go through this schema.
+ */
 declare const schemaHidAmicoSetConfiguration: Joi.ObjectSchema<any>;
 declare const schemaHidAmicoMonitor: Joi.ObjectSchema<any>;
 declare const schemaHidAmicoObjectOperation: Joi.ObjectSchema<any>;

package/dist/index.js

@@ -43463,7 +43463,10 @@ var schemaHidAmicoIntercomCall = import_joi64.default.object({
   target: import_joi64.default.string().trim().min(1).max(255).pattern(/^(?:sip:)?[A-Za-z0-9_.+-]+(?:@[A-Za-z0-9.-]+(?::\d{1,5})?)?$/).required()
 }).unknown(true);
 var schemaHidAmicoConfiguration = import_joi64.default.object().pattern(import_joi64.default.string(), import_joi64.default.array().items(import_joi64.default.string())).min(1).unknown(true);
-var schemaHidAmicoSetConfiguration = import_joi64.default.object().unknown(true);
+var schemaHidAmicoSetConfiguration = import_joi64.default.object({
+  pjsip: import_joi64.default.object().unknown(true),
+  identifier: import_joi64.default.object().unknown(true)
+}).min(1).unknown(false);
 var schemaHidAmicoMonitor = import_joi64.default.object({
   enabled: import_joi64.default.boolean().required()
 });
@@ -43672,6 +43675,9 @@ var SENSITIVE_KEYS = /* @__PURE__ */ new Set([
   "pin",
   "pin_value",
   "pinvalue",
+  "salt",
+  "salt_value",
+  "saltvalue",
   "card_value",
   "cardvalue",
   "cardno",