OpenFn / OpenFn/lightning

Validate UUIDs in LiveView mounts and search filters (Sentry LIGHTNING-3B)

Open
#4,804 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug Monitoring Sentry
Dominant language
Elixir
Stars
296
Forks
86
Avg merge
1d 13h
Merged PRs (30d)
50

Description

User story

Issue #4588 covers UUID validation across the REST API controllers (PR #4591 is an external contributor's attempt at it). This issue covers the remaining places Ecto.Query.CastError still surfaces from Sentry LIGHTNING-3B that #4588 explicitly scopes out: LiveView route params and search/filter inputs.

Details

LIGHTNING-3B (1,833 events, 11 users, still firing on v2.16.6) groups four distinct call sites under one Sentry fingerprint. #4588 enumerates the REST API ones. The remaining two:

  • /projects/:proj/w/<non-uuid>LightningWeb.WorkflowLive.Collaborate.workflow_assigns/2 (collaborate.ex:372) calls Workflows.get_workflow!("null") when the path param is the literal string "null". The new-workflow branch only fires when id is absent, not when it's a non-UUID. Seen 9× in the recent 90-day Sentry sample. Frontend is generating /w/null somewhere — worth a separate ticket.
  • Dataclips name-or-id filterLightning.Invocation.dataclip_where_filter/1id_prefix_interval/1 (invocation.ex:1037,1070) builds invalid UUID range bounds when users type non-hex text into the dataclips search box (e.g. IQ146-26-000-037). Seen 5× in the recent sample.
Implementation notes

Two patterns, drawn from common Phoenix practice:

  1. LiveView on_mount UUID validator — equivalent of the controller-level validator from #4588 but for LiveView. A shared on_mount callback (sibling to LightningWeb.Hooks.:project_scope) runs Ecto.UUID.cast/1 on known id params and redirects to 404 (or the new-workflow route) on :error. Apply to WorkflowLive.Collaborate at minimum; audit other LiveViews mounting on :id path params.
    • Narrower alternative: workflow_assigns/2 treats a non-UUID id the same as a missing one. Simpler but doesn't generalize.
  2. Filter input sanitizationid_prefix_interval/1 should reject non-hex input (or upstream, the LiveView assigning :name_or_id_part should validate before passing to dataclip_where_filter/1). Non-hex queries fall back to name-only search.

Whatever shared validate_uuid/1-style helper lands as part of #4588 should also be reachable from LiveView; worth coordinating so we don't end up with two implementations.

Release notes

Bug fix: invalid IDs in LiveView routes and dataclips search inputs no longer return 500.

User acceptance criteria
  • Navigating to /projects/:p/w/null or /projects/:p/w/<non-uuid> does not crash — either 404 or renders the new-workflow view
  • Dataclips search accepts arbitrary text (including dashes, non-hex chars) without 500
  • Frontend /w/null generation tracked as a separate follow-up

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with LightningWeb.WorkflowLive.Collaborate.workflow_assigns/2 in collaborate.ex:372 and Lightning.Invocation.dataclip_where_filter/1 with id_prefix_interval/1 in invocation.ex:1037,1070. Read issue #4588 and coordinate with its shared UUID helper before auditing other LiveViews with :id params. Done means invalid workflow IDs and arbitrary dataclips search text no longer produce 500 responses.

Written by the indexing model from the issue text.

Assessment

Tech stack
elixir
Domain
backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
54/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.