Skip to content

fix: validate config.activeTarget; warn-once on hand-edit typos#3

Merged
flamerged merged 1 commit into
masterfrom
fix/active-target-validation
May 1, 2026
Merged

fix: validate config.activeTarget; warn-once on hand-edit typos#3
flamerged merged 1 commit into
masterfrom
fix/active-target-validation

Conversation

@flamerged
Copy link
Copy Markdown
Owner

Fixes review item #15: activeTarget was not validated when the config was hand-edited externally — daemon silently kept polling a dead remote with no surface signal except log file errors.

Behavior change

  • Validate activeTarget against config.remotes ∪ {'local', initialRemote} on every poll cycle.
  • If invalid, log a one-shot warning (named bad value, known-good list, fallback) and stick with the last known-good target.
  • Re-warn only when the bad value changes — prevents log spam at the 200ms poll cadence.
  • Resets warning state when a valid value lands again.

Smoke test

  1. Daemon running, target = 'local'
  2. Hand-edit ~/.config/sshshot/config.json to activeTarget: 'typo-host'
  3. Within ~200ms, log shows the warning ONCE; daemon stays on 'local'
  4. Set activeTarget back to a valid value via sshshot target local; daemon picks it up cleanly

…t typos

Before: if a user hand-edits ~/.config/sshshot/config.json and sets
activeTarget to a typo'd or removed remote (e.g. 'cidatel' instead of
'citadel'), the daemon happily polled that value forever. Every
screenshot upload silently failed at the SSH layer; the only signal
was lines in the log file.

Now: the daemon validates activeTarget against config.remotes (plus
'local' and the original start-time target) on each poll cycle. If
the value isn't in the valid set:
- Log a one-shot warning naming the bad value, the known-good targets,
  and the fallback that will be used
- Stick with the last known-good target (or the start-time target on
  first poll)
- Re-warn only if the bad value changes (so a typo sitting there
  doesn't spam logs at 5 Hz)

When a subsequent valid value lands, the warning state resets so the
*next* invalid value (if any) re-warns once.
@flamerged flamerged merged commit 705bbe3 into master May 1, 2026
2 checks passed
@flamerged flamerged deleted the fix/active-target-validation branch May 1, 2026 12:56
@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 1, 2026

🎉 This PR is included in version 0.4.3 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

flamerged added a commit that referenced this pull request May 1, 2026
Phase 5 'big' item #3 of 3.

## What

- Auto-detect Wayland vs X11 via `XDG_SESSION_TYPE` / `WAYLAND_DISPLAY`
- Wayland path: `wl-paste --type image/png` (read) + `wl-copy` (write)
- X11 path: existing `xclip` code path, unchanged
- Startup warning is session-aware (wl-clipboard hint for Wayland, xclip
hint for X11)
- Banner / log shows 'Linux (Wayland)' or 'Linux (X11)' so users see
which path is active

## Why

Modern Ubuntu/Fedora/etc. default to Wayland; xclip silently fails
there. ~50% of Linux users were getting silent clipboard no-ops before
this change.
flamerged added a commit that referenced this pull request May 1, 2026
…, clipboard reads (#14)

Four items from the latest project review (P3/P4 cleanup):

| # | Item |
|---|------|
| #2 | `getPidFile` deduped into config.ts (single source of truth) |
| #3 | `taskkill` via spawnSync with array args |
| #5 | `startBackground` Linux/macOS path: nohup execSync → spawn
detached (closes the `\${remote}` shell-injection surface; the original
'native clipboard library crashes with detached' rationale is obsolete
since @crosscopy/clipboard was removed) |
| #6 | xclip / wl-paste / pngpaste / defaults clipboard reads via
spawnSync |

Net: zero remaining execSync calls with user-controlled string
interpolation. All tests still pass.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant