feat(node-red): add valet/guest/speed-limit commands with PIN/password redaction - #97
Conversation
…d redaction Wraps the already-existing setValetMode/setPinToDrive/speedLimit*/setGuestMode SDK methods in the vehicle-command node's switch-case, following its existing on/off command-splitting pattern. Adds a `sensitive` flag to validateParameters so a bad PIN or password is never echoed into the node's error/status text - only "[redacted]" is, keeping it out of the debug sidebar and Node-RED log. Also adds a tsx --test suite for node-red-contrib-teslemetry, bringing it in line with the rest of the monorepo's test convention.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 74f9f03ffd
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| validateParameters(msg, { | ||
| password: { required: true, type: "string", sensitive: true }, | ||
| }); | ||
| result = await vehicle.setValetMode(true, msg.password); |
There was a problem hiding this comment.
Strip sensitive fields before forwarding messages
When any newly added password/PIN command succeeds, the handler later forwards the original object with send(msg), leaving msg.password or msg.pin intact; a downstream Debug node configured for the complete message will therefore expose the secret despite the documented redaction guarantee. Validation failures likewise pass the unchanged message to node.error(..., msg), making the secret available to Catch flows. Remove these fields before either success or error forwarding rather than only redacting the validation error string.
Useful? React with 👍 / 👎.
Intent
teslemetry-vehicle-command- Guest Mode, Valet Mode, PIN to Drive, and Speed Limit Mode. The@teslemetry/apiSDK already exposes all of these (setGuestMode,setValetMode,resetValetPin,setPinToDrive,clearPinToDriveAdmin,resetPinToDrive,clearPinToDrive,speedLimitActivate/Deactivate/ClearPin/ClearPinAdmin/SetLimit); this just wires them into the node's existing switch-case, following its on/off command-splitting pattern (mirrorssetSentryModeOn/setSentryModeOffetc).setValetModeOn/Off,setPinToDriveOn/Off,clearPinToDrive,speedLimitActivate/Deactivate/ClearPin) validatemsg.password/msg.pinas required strings viavalidateParameters.resetValetPin,clearPinToDriveAdmin,resetPinToDrive,speedLimitClearPinAdmin) take no PIN/password - they're already-authenticated overrides for a lost credential.sensitiveflag toValidationRule(src/validation.ts). When a validation failure occurs on asensitivefield, the thrown error redacts the actual value as[redacted]instead of echoing it, so a bad PIN/password never ends up in the node's status text ornode.erroroutput (debug sidebar / Node-RED log).test/suite (tsx --test, matching the other four packages' convention) covering the redaction behavior, sincenode-red-contrib-teslemetryhad none yet.