Validate device names on rename so users don't brick a device profile

[mrramam]

A device name containing / bricks that device: the dashboard stops rendering, and the device cannot be deleted through the UI either.

The failure

The client escapes the name correctly — getDeviceApiBase uses encodeURIComponent, so / becomes %2F. nginx decodes it before proxying, so /api/devices/<name>/settings splits into a path that matches no route, and every request for that device 404s. Deleting it goes through the same path shape, so the UI offers no way out.

Reproduced on a stock instance:

PUT /api/devices/Kitchen%20Display/settings   -> 200   (a space is fine)
PUT /api/devices/a%2Fb/settings               -> 404   (the bug)

The fix, and one thing it deliberately does not do

Validation happens on rename only — the one place a human chooses a name. Reads are untouched, and ensureDeviceExists is unchanged.

That restraint is the important part. An earlier revision of this change validated on the lookup path too, which meant an existing device called Kitchen Display would start failing on upgrade — breaking displays that work today in order to fix ones that are already broken. An existing row's name is a fact about the world; rejecting a name the application previously accepted and stored is not a fix.

For the same reason there is no migration and no sweep. Repairing an install that already holds a bad name would require rewriting the name server-side and in every browser's localStorage, since the client holds its own identity and would keep requesting the old one. That is a permanent cost on every page load of every install, to fix a rare condition. getDeviceName still returns exactly what is stored.

The rule

An allow-list rather than a deny-list, so it stays correct if HomeGlow is fronted by Caddy or Apache, or by nginx with different merge_slashes settings:

/^[\p{L}\p{N} _\-.'()]+$/u

Unicode letters and digits, space, and the punctuation people actually use for a screen in their house — Kitchen Display, Nan's iPad, Playroom (up), José. Characters carrying URL meaning (/ \ % ? # & + : @) are excluded even where the current nginx tolerates them.

Plus: NFC-normalised so an accented name typed two ways cannot produce two devices that look identical; 1–64 characters after trimming; at least one letter or digit; no ...

The charset is intentionally broader than the bug strictly requires. Only / is known to break today — but %, ? and # have URL meaning that a different front end may well act on, and a device name has no need of them.

Client side

The rename dialog validates as you type, disabling the confirm action with inline helper text, so the server 400 is a backstop rather than the user's first encounter with the rule. Both implementations are checked against each other; an earlier revision diverged because RegExp.prototype.test() coerces its argument, so isValidDeviceName(undefined) tested the string "undefined" and returned true on the client while the server returned false.

Testing

server/tests/deviceName.test.js and client/src/utils/deviceName.test.js cover the valid names above, /, .., whitespace-only, pure punctuation, over-length, and non-string inputs — plus a case asserting the two NFC spellings of an accented name resolve to the same device.

Full suites on Node 20 (matching ci-tests.yml): backend 190 passing, frontend 120 passing, check:i18n 715/715, client build clean.

[jherforth]

Merged — nice piece of work. The reasoning about validating on rename only, and deliberately not shipping a migration, is the right call and well argued.

One little tweak pushed on top in b7951d2: the allow-list was \p{L}\p{N}, which quietly excludes any script that keeps its vowel signs in the Mark category — so Hindi and Thai device names bounced. Added \p{M}, which lets those through while /, %, ?, # and .. stay rejected, and zero-width joiners and bidi overrides stay out too since they're \p{Cf} rather than marks. Left DEVICE_NAME_HAS_ALNUM alone so a string of bare combining marks still isn't a name.

Admittedly this only unblocks our enormous install base across India and Thailand, who I'm sure have been queuing up to name a kitchen tablet — but the fix was one character class, so it seemed rude not to.

Tests added both sides. 208 backend / 122 frontend, build clean.