Skip to content

Restore JSON auth for test_instances#search (mesa_test API path)#91

Merged
wmwolf merged 1 commit into
masterfrom
fix-search-json-auth-regression
May 26, 2026
Merged

Restore JSON auth for test_instances#search (mesa_test API path)#91
wmwolf merged 1 commit into
masterfrom
fix-search-json-auth-regression

Conversation

@wmwolf
Copy link
Copy Markdown
Member

@wmwolf wmwolf commented May 26, 2026

What broke

Commit b8542bc (Sep 15, 2025) — "Restrict most pages to logged-in users to reduce traffic" — added a global authorize_user before_action to ApplicationController with a curated list of skip_before_action exemptions. The list covered login/sessions, GitHub webhooks, the submissions API, and computer auth, but missed TestInstancesController#search and #search_count, which had their own action-level email/password auth (added by 6112b7f back in 2019).

The result: since September 2025, every JSON call to /test_instances/search.json and /test_instances/search_count.json from mesa_test (or any other CLI client) has been silently 302'd to /login instead of authenticating with the supplied email/password and returning results. The action-level authenticated? helper became dead code.

What this PR does

  • Skip the global authorize_user for both JSON endpoints on TestInstancesController. The action body still enforces auth via the existing authenticated? helper (session-first, falling back to email + password params).
  • Re-impose the HTML login gate via a tiny gate_html_search_to_authenticated_users before_action, so b8542bc's intent ("reduce anonymous browse traffic") is preserved for the browser path.
  • Why not skip_before_action :authorize_user, only: [:search], if: -> { request.format.json? }? Tried it — the lambda doesn't appear to be consulted consistently on skip_before_action in Rails 8 (the HTML path bypassed authorize_user even with if: format.json?). The explicit method-based gate is easier to reason about anyway.

Test plan

  • New spec/requests/test_instances_search_auth_spec.rb — 8 examples pinning every cell of the auth matrix:
    • HTML anonymous → 302 to /login
    • HTML authenticated → 200
    • JSON anonymous (no creds) → 422 JSON error (not 302)
    • JSON wrong creds → 422 JSON error
    • JSON valid email/password → 200 results
    • JSON via browser session → 200 results
    • search_count.json same shape (anonymous → 422 error; with creds → 200 count)
  • Full suite green: 312 examples, 0 failures.

Severity

External clients have been broken for ~8 months. This should merge ahead of #90 (the branch-filter + SHA-fix work, which sits cleanly on top of this fix).

The JSON variants of #search and #search_count are the API path that
mesa_test (and any other CLI client) hits to read past test
instances. They authenticate per-request via email + password params
inside the `authenticated?` helper — no browser session involved.

Commit b8542bc (Sep 2025), which added a global authorize_user
before_action to ApplicationController to reduce anonymous browse
traffic, exempted login/sessions, GitHub webhooks, the submissions
API, and computer auth — but missed this controller. Every external
JSON caller has been getting silently 302'd to /login since then.
The action-level email/password auth code went dead because the
filter chain redirected before the action body ever ran.

Skip the global filter for both JSON endpoints. Re-impose login for
the HTML search page via a small `gate_html_search_to_authenticated_users`
before_action so b8542bc's intent (gated browse) is preserved. The
conditional `if: -> { request.format.json? }` form of
skip_before_action would have been the natural shape here, but the
lambda doesn't seem to be consulted consistently in Rails 8 — the
explicit method-based gate works and is easy to read.

New spec/requests/test_instances_search_auth_spec.rb pins the
behaviour: HTML anonymous → 302 to /login; JSON without creds →
422 JSON error (not a redirect); JSON with valid email/password →
200 results; JSON with valid session → 200 results;
search_count JSON behaves the same way.
@wmwolf wmwolf merged commit 5ba853a into master May 26, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant