[newsfeed] add allowBasicHtmlTags option for basic emphasis

[egeekial]

Please make sure that you have followed these 3 rules before submitting your Pull Request:

1. Base your pull requests against the develop branch.
   Done.
2. Include these infos in the description:

• Does the pull request solve a related issue?
  No
• If so, can you reference the issue like this Fixes #<issue_number>?
• What does the pull request accomplish? Use a list if needed.
• If it includes major visual changes please add screenshots.

Render a strict allowlist of basic formatting tags (b, strong, i, em, u) in news titles and descriptions, while neutralizing all other HTML.

Feeds such as The Atlantic encode emphasis as entities (<em>), which html-to-text decoded to a literal string that the template then auto-escaped, so the raw tag was shown on screen. The new opt-in allowBasicHtmlTags option (default false) sanitizes both fields by escaping everything and restoring only the exact, attribute-free allowlisted tags, so the result is safe to render and arbitrary HTML/script injection is impossible.

Adds unit tests for the sanitizer and an e2e test covering rendering and an injection attempt.

Before screenshot:
After screenshot:

3. Please run node --run lint:prettier before submitting so that
   style issues are fixed.
   Done

Note: Sometimes the development moves very fast. It is highly
recommended that you update your branch of develop before creating a
pull request to send us your changes. This makes everyone's lives
easier (including yours) and helps us out on the development team.

Thanks again and have a nice day!

[sdetweil]

do you ever envision the user wanting/needing to adjust the list of tags

in newfeedfetcher.js

const ALLOWED_TAGS = ["b", "strong", "i", "em", "u"];

if this is approved, will you also create a matching PR for the documentation repo?

[egeekial]

do you ever envision the user wanting/needing to adjust the list of tags

in newfeedfetcher.js

const ALLOWED_TAGS = ["b", "strong", "i", "em", "u"];

My intent was to keep this limited to basic formatting and make the feature something users can simply turn on or off. I could imagine a user wanting finer control, such as allowing italics but not bold or underline, but I suspect most users would not want or need that level of granularity.

If you think that configurability would be beneficial, I would prefer exposing it as a subset of the existing safe list rather than allowing users to add arbitrary tags. Letting users add new tags seems more likely to create rendering issues or introduce an injection risk.

if this is approved, will you also create a matching PR for the documentation repo?

Yes, I can do that.

[KristjanESPERANTO]

I think this is a useful improvement. Thanks! :)

Building on @sdetweil’s point about configurability, I think a single option like allowedBasicHtmlTags instead of a boolean would be nice.

Suggested behavior:

• default: [] (so current behavior stays unchanged)
• users can choose only from a hardcoded safe list (like ["b", "strong", "i", "em", "u", "br", "code", "s", "sub", "sup"])
• any unknown/unsafe tags are ignored (optionally with a warning)

This would keep the security model strict, avoids surprising defaults, no need for multiple options and still gives users flexible control. I think it should be possible to implement this with a reasonable level of complexity.

[rejas]

I think this is a useful improvement. Thanks! :)

Building on @sdetweil’s point about configurability, I think a single option like allowedBasicHtmlTags instead of a boolean would be nice.

Suggested behavior:

* default: `[]` (so current behavior stays unchanged)

* users can choose only from a hardcoded safe list (like `["b", "strong", "i", "em", "u", "br", "code", "s", "sub", "sup"]`)

* any unknown/unsafe tags are ignored (optionally with a warning)

This would keep the security model strict, avoids surprising defaults, no need for multiple options and still gives users flexible control. I think it should be possible to implement this with a reasonable level of complexity.

I totally agree: nice pr and idea, but needs a little tweaking like kristjan proposes.

[sdetweil]

• users can choose only from a hardcoded safe list (like ["b", "strong", "i", "em", "u", "br", "code", "s", "sub", "sup"])

I don't know enough about the tags in the content. Are we sure this is the finite list.. (without us having to take PRs every so often, slowing functional delivery.

One thing I've learned over the years is that I learn new stuff constantly about how users expect the system to behave.

I like the PR, and the selectable list..

[KristjanESPERANTO]

After the last commit I'm fine with the current state 🙂 But since other maintainers were involved in the discussion, I don't want to make the decision about merging alone.

[rejas]

Im fine with it too. what about you @sdetweil ?

[sdetweil]

it looks ok. We will find out if the list is enough

[KristjanESPERANTO]

@egeekial Many thanks for this! 😃

if this is approved, will you also create a matching PR for the documentation repo?

Yes, I can do that.

It would be great if you could create the PR for the docs before the July 1 release.

[KristjanESPERANTO]

@egeekial Feedback would be nice, even if you can't do it 🙂

[egeekial]

Follow-up: opened a documentation PR for this option over in the docs repo — MagicMirrorOrg/MagicMirror-Documentation#387.