fix(star-rating): check consent link destinations as urls (24.05)

[ar2rsawseen]

Backport of #7886 to release.24.05, which carries the same code. See that PR for the full analysis.

Consent links are rendered into anchors in the drawer preview and the public popup, and nothing checked that a destination was a usable url — so anything typed into that field became the href.

Both render paths escape the value, and escaping cannot cover this: it touches <, > and &, and javascript:alert(1) contains none of them, so the value arrives unchanged and the browser runs it when the link is clicked.

Checked in three places, because they are three runtime contexts that have to agree or a value refused in one renders in another: the widget endpoint (in the shared links preprocessor, which both create and edit run), the dashboard drawer, and the popup page, which shares no code with the dashboard.

The render-side checks are not redundant. Widgets stored before this change still carry whatever was saved; without them those links keep working until someone re-saves the widget.

Accepted: http(s), a root-relative path, or a fragment, matching what countlyCommon's onTagAttr already permits for an href elsewhere. Leading whitespace and control characters are stripped first, since a browser ignores them when resolving a url, and protocol-relative //host is refused.

Also escapes link labels before building the regular expression they are matched with: unescaped, a label is a pattern, and one like (a+)+$ turns matching into catastrophic backtracking.

Notes on this branch

The api and drawer changes applied unchanged. The popup template differs here, so that part was hand-authored to match.

58 unit tests, all passing here. Full unit suite 101 passing before, 159 after, same 5 pre-existing failures. eslint clean.

🤖 Generated with Claude Code

[ar2rsawseen]

Pushed a follow-up commit that narrows the accepted set to http(s) only.

The first pass allowed a root-relative path and a fragment as well, on the reasoning that countlyCommon's onTagAttr permits those for an href elsewhere in the dashboard. The closer precedent is the surveys widget, which renders the same kind of consent link and already accepts http(s) only, falls back to about:blank, and sets rel on the anchor (plugins/surveys/frontend/public/javascripts/countly.common.components.js). The two widgets sit next to each other and do the same job, so having them disagree on what a link may point at is the outcome worth avoiding.

Dropping relative paths costs nothing here: the popup is served from the Countly server, so /terms would resolve against the server rather than against the site the widget is embedded in.

Also in this commit:

• both renderers fall back to about:blank rather than an empty href, which would have pointed the link at the current page and reloaded it on click
• both anchors carry rel="noopener noreferrer"
• the drawer escapes the href it builds, since that string is handed to v-html and a value that passes the scheme check can still carry a quote
• the CHANGELOG line no longer mentions relative paths and fragments

Tests updated to match: /terms and #terms moved to the refused set, a whitespace-padded url and a mailto: case added, and two cases assert the render sites use the about:blank fallback and set rel. 68 passing, eslint clean.