Add recon job UI against the Common Lisp backend; no browser-side provider implementations #170

New issue

Open

opened 2026-08-16 05:23:40 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-16 05:23:40 +00:00

(Migrated from github.com)

Problem

Quasar UI needs investigation/recon affordances, but implementing Shodan/Censys/URLScan/etc directly in browser JavaScript would duplicate backend logic and expose provider credentials. Existing #128 already documents dangerous browser-side secret persistence/redirection behavior.

Current behavior

Quasar's Common Lisp control plane is authoritative for migrated durable state.
lost-rob0t/quasar#32 tracks provider-neutral recon commands in that control plane.
provider/security state in the browser is already a known P1 risk (#128).

Desired behavior

Add only the browser boundary needed to start, observe, cancel, and inspect backend recon jobs.

The UI should conceptually support:

start recon for a typed domain/url/host/ip asset
choose capability/provider policy where permitted (auto, a named provider, all)
display queued/running/completed/failed/cancelled state
stream/refresh typed results and errors
cancel a job
send accepted results into the existing workspace/document flow

Use Quasar's existing WebSocket/control-plane conventions if #32 lands there. Do not introduce a second unrelated REST/RPC layer unless the existing transport genuinely cannot support the job model.

Security boundary

no Shodan/Censys/SecurityTrails/VirusTotal/etc secret in frontend code or job payloads
no frontend provider adapter that directly calls credentialed APIs
backend results/events must be scrubbed of configured secrets
follow #128's credential hardening rather than expanding browser secret scope

Dependencies

lost-rob0t/quasar#32 backend recon capability commands
#128 provider credential security
Hackmode canonical provider/asset work: lost-rob0t/hackmode#2 and #6

Acceptance criteria

real UI action starts a backend recon job through the existing control-plane client
status/results/cancel use backend job identifiers
browser code contains no provider API secrets or credential-bearing vendor calls
failure from one provider is presented without breaking other results/job controls
typed results can be handed to the existing Quasar document/graph flow
refresh/reconnect restores job state from backend rather than inventing browser authority

Verification

UI integration tests against a fake control-plane recon command/event stream
test cancel and provider failure
static test/assertion that recon requests contain no provider secret
test reconnect/status restoration
manual browser network inspection shows only Quasar backend/control-plane traffic for credentialed providers

## Problem Quasar UI needs investigation/recon affordances, but implementing Shodan/Censys/URLScan/etc directly in browser JavaScript would duplicate backend logic and expose provider credentials. Existing #128 already documents dangerous browser-side secret persistence/redirection behavior. ## Current behavior - Quasar's Common Lisp control plane is authoritative for migrated durable state. - lost-rob0t/quasar#32 tracks provider-neutral recon commands in that control plane. - provider/security state in the browser is already a known P1 risk (#128). ## Desired behavior Add only the browser boundary needed to start, observe, cancel, and inspect backend recon jobs. The UI should conceptually support: - start recon for a typed domain/url/host/ip asset - choose capability/provider policy where permitted (`auto`, a named provider, `all`) - display queued/running/completed/failed/cancelled state - stream/refresh typed results and errors - cancel a job - send accepted results into the existing workspace/document flow Use Quasar's existing WebSocket/control-plane conventions if #32 lands there. Do not introduce a second unrelated REST/RPC layer unless the existing transport genuinely cannot support the job model. ## Security boundary - no Shodan/Censys/SecurityTrails/VirusTotal/etc secret in frontend code or job payloads - no frontend provider adapter that directly calls credentialed APIs - backend results/events must be scrubbed of configured secrets - follow #128's credential hardening rather than expanding browser secret scope ## Dependencies - lost-rob0t/quasar#32 backend recon capability commands - #128 provider credential security - Hackmode canonical provider/asset work: lost-rob0t/hackmode#2 and #6 ## Acceptance criteria - real UI action starts a backend recon job through the existing control-plane client - status/results/cancel use backend job identifiers - browser code contains no provider API secrets or credential-bearing vendor calls - failure from one provider is presented without breaking other results/job controls - typed results can be handed to the existing Quasar document/graph flow - refresh/reconnect restores job state from backend rather than inventing browser authority ## Verification - UI integration tests against a fake control-plane recon command/event stream - test cancel and provider failure - static test/assertion that recon requests contain no provider secret - test reconnect/status restoration - manual browser network inspection shows only Quasar backend/control-plane traffic for credentialed providers