Test sprockets remove

[harshaellanki]

PR Checklist

Please check if your PR fulfills the following requirements:

• The title follows our guidelines
• Tests for the changes have been added (for bug fixes/features), and they use let helpers and before blocks.
• For all UI changes, there is Cucumber coverage.
• Any endpoint touched in the PR has an appropriate Pundit policy. For open endpoints, the reasoning is documented in the PR and code.
• Any endpoint modified in the PR only responds to the expected MIME types.
• For all scripts or rake tasks, how to run them is documented in both the PR and the code.
• There are no inline styles added.
• There is no inline JavaScript added.
• There is no hard-coded text added/updated in helpers/views/JavaScript. New/updated translation strings do not include markup/styles unless there is supporting documentation.
• Code does not use .html_safe.
• All images added/updated have alt text.
• Does not bypass RuboCop rules in any way.

PR Type

What kind of change does this PR introduce?:

• Bugfix
• Feature (requires Feature flag)
• Data fix, Migration, or Report (inert code, no impact until run)
• Refactoring (no functional changes, no API changes)
• Build related changes
• CI related changes
• Dependency updates (e.g., add a new gem or update to a version)
• Release (Prepares code for a release, e.g., version bumps, changelog updates, tagging, deployment scripts)

What is the ticket # detailing the issue?

Ticket:

A brief description of the changes:

Current behavior:

New behavior:

Feature Flag

For all new feature development, a feature flag is required to control the exposure of the feature to our end users. A feature flag needs a corresponding environment variable to initialize the state of the flag. Please share the name of the environment variable below that would enable/disable the feature and indicate which client(s) it applies to.

Variable name:

• DC
• ME

Additional Context

Include any additional context that may be relevant to the peer review process.

In general, to fix an untrusted redirect, we must not redirect to arbitrary user-provided URLs. Instead, we should either (a) validate that the URL is on the same host and uses an expected scheme, or (b) allow only relative paths and optionally validate them against a whitelist or pattern. Since there are multiple callers all going through redirect_back_safely, the best fix is to strengthen this helper so that any untrusted input passed to it is validated consistently.

Concretely, we will modify ApplicationController#redirect_back_safely (lines 118–125) to:

1. Reject blank or nil return_to_path values and immediately redirect to the fallback.
2. Parse return_to_path with URI.parse but, importantly:
   • Treat relative paths (no scheme and no host, starting with /) as safe and redirect to them.
   • For absolute URLs, allow them only if:
     • The scheme is http or https, and
     • The host matches request.host.
3. For anything else (invalid URI, different host, non-http(s) scheme, or suspicious path), use the fallback.

This change keeps the public interface of redirect_back_safely unchanged, so we do not need to touch the callers in Insured::ConsumerRolesController or Insured::GroupSelectionController; the new, stricter checks will automatically apply to all 11 CodeQL alert variants. We can implement this with plain Ruby and Rails, using the existing URI class that is already being used in the method. No new methods or imports are strictly required beyond the updated logic.

---

In general terms: avoid directly trusting text pulled from the DOM when using it in a navigation context. Before assigning to window.location.href, restrict the URL to expected safe values (e.g., same-origin, HTTP(S), and optionally specific path patterns). This avoids situations where DOM text bypasses earlier encoding or where an attacker injects a dangerous URL (such as javascript:alert(1) or a cross-domain phishing URL).

Best specific fix here: validate and normalize the URL from #add_dental_url before using it. A robust, non-invasive approach is:

1. Read the raw URL string from #add_dental_url.
2. Attempt to construct a URL object from it:
   • If it’s relative, resolve it against window.location.origin.
3. Enforce that:
   • The protocol is http: or https:.
   • The hostname matches window.location.hostname (to prevent open redirects), or at least is within allowed hosts.
4. If the URL fails validation, either:
   • Abort navigation, or
   • Fallback to a known safe URL.
5. Only then build window.location.href with the profile_id parameter, ideally using encodeURIComponent on the profile id.

We only touch the shown snippet in AddDentalToPlanDesignProposal. Concretely, we will:

• Replace:

  var url = $("#add_dental_url").val()
  window.location.href = url + "&profile_id=" + $("#profile_id").val()

• With code that:

  • Reads rawUrl and profileId.
  • Safely constructs a URL object, resolving relative URLs.
  • Checks protocol and hostname.
  • If valid, appends/overwrites the profile_id query parameter using the URL API (searchParams.set), ensuring correct escaping.
  • Assigns the resulting url.toString() to window.location.href only if valid.

This approach preserves existing behavior (navigate to whatever #add_dental_url points to, plus the profile_id parameter) but prevents malformed or hostile URLs from being used.

No new imports are needed; URL and window.location are standard Web APIs.

General approach: Ensure that any data coming from the DOM ($("#profile_id").val()) is (a) constrained to an expected format and (b) properly URL-encoded before being concatenated into a URL used for navigation. This removes the possibility of breaking the query string structure or injecting unexpected characters.

Best concrete fix here without changing existing behavior:

1. Extract the profile_id value into a local variable.
2. Optionally constrain it to an expected pattern (e.g., numeric or alphanumeric) using a simple validation; if it fails, either do not append it or handle the error.
3. Apply encodeURIComponent before appending it to data.url.
4. Use the encoded value both in the success handler (line 636) and in the error handler (line 641) to keep behavior consistent.

We only touch app/javascript/components/sponsored_benefits/plan_design_proposals.js within the shown snippet. No new imports are needed; encodeURIComponent is a standard global. The changes are:

• Inside success: function(data) { ... }, introduce a var profileId = $("#profile_id").val(); and then use encodeURIComponent(profileId) when concatenating to data.url.
• Inside error: function(data) { ... }, similarly extract and encode profileId, then build assembled_url with the encoded value and pass that to window.location.replace.

This preserves the existing flow and logic while ensuring that meta-characters in profile_id are safely encoded before being embedded in the URL.

In general, when taking text from the DOM and using it in contexts where meta-characters are meaningful (HTML, JavaScript, URLs, selectors), you should either (a) validate it against an expected pattern and reject anything unexpected, and/or (b) encode/escape it appropriately for the context (e.g., encodeURIComponent for query parameters, HTML escaping for HTML contexts).

For this specific issue, the problematic use is building a URL query string "...&profile_id=" + $("#profile_id").val() and assigning it to window.location.href. The safest, least intrusive fix that preserves existing functionality is to URL-encode the profile_id value using encodeURIComponent before concatenating it. This ensures any special characters in the DOM value are percent-encoded and cannot break out of the intended parameter value or introduce HTML/JavaScript into other contexts, while still yielding the same semantics for typical alphanumeric IDs.

Concretely, in app/javascript/components/sponsored_benefits/plan_design_proposals.js, inside the saveProposalAndPublish function, update line 636 to:

window.location.href = data.url + "&profile_id=" + encodeURIComponent($("#profile_id").val());

and leave the rest of the function unchanged. No new imports or helper methods are required because encodeURIComponent is a built-in global in JavaScript.

---