Potential fix for code scanning alert no. 5: Unsafe jQuery plugin

[gruble]

Potential fix for https://github.com/NVE/regobs-ocr/security/code-scanning/5

General approach: Ensure that any potentially user-influenced value that is intended to be a DOM element (or a collection of elements) is not interpreted by jQuery as HTML. For validationTargetFor, the intention is “take an element (or element set) and apply the ignore filter”; there is no legitimate use case where a raw HTML string should be passed in. We can therefore normalize its argument to a DOM element and avoid calling $() on arbitrary strings.

Best concrete fix: Change validationTargetFor so it never passes a potentially string-typed element directly into $(). Instead:

• If element is already a DOM element, wrap it in $() safely.
• If it is a jQuery object, use it directly.
• If it is anything else (e.g., a string), treat it as “no valid element” and return undefined instead of letting jQuery parse it as HTML.

We’ll implement this by reusing the plugin’s clean helper—which already does return $( selector )[ 0 ]; and is always used with selectors rooted at this.currentForm or with elements—to normalize input to a DOM element, and then wrap that element with $( element ). This avoids $() ever seeing untrusted HTML, while preserving existing behaviour for proper inputs.

Concretely in SnowProfileScanner/wwwroot/lib/jquery-validation/dist/jquery.validate.js:

• Replace the body of validationTargetFor with a version that:
  • Calls this.clean( element ) to normalize its argument to a single DOM element.
  • If the result is falsy, returns it directly.
  • Otherwise applies the ignore filter with $( element ).not( this.settings.ignore )[ 0 ];.

No new imports or external dependencies are needed.

Suggested fixes powered by Copilot Autofix. Review carefully before merging.