[DEMO] A/B test demonstration

[matt-bernhardt]

This PR is meant to demonstrate how an A/B testing framework might function within our Rails applications. It is only a demonstration.

To see the experiment
When users visit the application, they'll be randomly selected into one of two groups. Each will be shown one version of the experiment. As of 1/7/25, the two versions look like this:

1. The baseline (imagine this is the normal state of things). To see this version explicitly, append ?ab_test[ui_colors]=standard to the URL.

2. The alternative (this is the change being tested). To see this version explicitly, append ?ab_test[ui_colors]=alt to the URL.

To see the results
The results dashboard can be seen at the /split path. The Split gem will collect data, and should report results when they become available.

Developer

• All new ENV is documented in README
• All new ENV has been added to Heroku Pipeline, Staging and Prod
• ANDI or Wave has been run in accordance to
  our guide and
  all issues introduced by these changes have been resolved or opened as new
  issues (link to those issues in the Pull Request details above)
• Stakeholder approval has been confirmed (or is not needed)

Code Reviewer

• The commit message is clear and follows our guidelines
  (not just this pull request message)
• There are appropriate tests covering any new functionality
• The documentation has been updated or is unnecessary
• The changes have been verified
• New dependencies are appropriate or there were no changes

Requires database migrations?

NO

Includes new or updated dependencies?

YES

In general, to fix untrusted URL redirection you must avoid redirecting directly to arbitrary user input. Instead, you either (a) map a small, controlled set of keys to full redirect URLs on the server, or (b) validate the supplied URL so that only acceptable targets (for example specific hosts or schemes) are allowed, and reject or replace everything else with a safe default.

For this specific RecordController#out method, the least invasive fix that preserves existing behavior (redirecting to external links for A/B testing) is to validate the params[:url] using Ruby’s URI parsing and an allow‑list of acceptable schemes (typically just http and https). This still allows external redirects but prevents obviously malicious or malformed inputs (e.g., javascript: URLs). Since the controller already opts in to allow_other_host: true, we should not restrict by host without additional business requirements, but we can at least ensure the value parses as a URI and has an allowed scheme, or is a relative path. If validation fails or parsing raises an exception, we redirect to a safe fallback ('/'), just as the current code does in the “no url” case.

Concretely, in app/controllers/record_controller.rb:

• Add a small private helper method, e.g., safe_redirect_url, that takes the raw params[:url], returns a String if it’s a valid and allowed target, and returns nil otherwise. It should:
  • require 'uri' at the top of the file to use URI.parse.
  • Accept nil or blank values and treat them as invalid (return nil).
  • Attempt to parse the URL with URI.parse.
  • Allow redirects if:
    • the parsed URI has no scheme and no host (a relative URL), or
    • the scheme is http or https (case-insensitive).
  • Rescue URI::InvalidURIError and treat as invalid.
• Update out to use this helper: compute target_url = safe_redirect_url(params[:url]). If target_url is present, call ab_finished(:result_format) and redirect_to target_url, allow_other_host: true; otherwise, redirect to '/' without calling ab_finished.

This approach keeps the observable behavior the same for valid, typical outbound links but adds robust validation, addressing the CodeQL finding.