Allow Views Rewrite Results to include inline SVGs

Since this is done by XSS::filterAdmin I would say that this is working as designed, so any changes we make would be a new feature.

There are more requests floating around about people trying to get around the restrictions of only using XSS allowed tags, so maybe it would be worthwhile to allow admins to swap out the used filter in some way. Don't know, just thinking out loud.

Should I change this issue to that: "Use CKEditor filtering in views re-write results" ?

that might work as long as we don't create a dependency on CKEditor in Views. Haven't looked at what CKEditor does so don't know how viable this is, but somehow being able to switch to different filter settings sounds something that would be attractive for a lot of people.

I just ran into the need of adding an SVG in views rewrite. I would also like to see this feature added.

@kenton.r Ditto that.

Very important. I use it like that and that will not work in views because stripped out

This is no special custom tag: https://developer.mozilla.org/en-US/docs/Web/SVG/Element/use
Guess i need to hack core again because of a tag.

#2687479: Responsive Image not working in rewritten Views field/area due to XSS filtering

@marcoka or anyone - do I still need to hack core to allow the svg tag in my View? If so what do I need to do?

reply to myself - permitted html tags are listed in /core/lib/Drupal/Component/Utility/Xss.php but a better option is to use a views template (such as views-view-fields--my-view-here.html.twig) which has no html restrictions.

Juc1 yes you need to. DI it today, again.

Following this issue as it is a feature that we need.

Until a better solution gets used (ex. override through settings.php or alter hook), I attach a patch which targets the whole Xss class and not Views specifically and adds the SVG and PATH tags to the adminTags array.

I would even consider removing the "views.module" from the issue's "Component" value - either way it's core though it's usually depicted when using views.

I also encountered this issue. Ideally, there should be another toggle under "Rewrite Results" to skip the Xss::filterAdmin filter.

For now, I'm using the "Rewrite Results" toggle itself for this purpose. See the attached patch. It was written for Drupal 10.1.4, but it'll probably work on other versions.

Well, I would say that your patch goes to a more opinionated and insecure approach which would work in my scenario too, yes, but it would compromise all views - even if it is not required. From adding two extra tags as allowed to throwing filtering completely out, well there definitely is a gap.

From what I had read in code and comments etc and understood, I would have expected the HTML template coming from Drupal Views UI to be XssAdmin-filtered, yes, but when TWIG is used no extra processing should be done. In that case I could have separate TWIG files in my theme containing the SVG file only and then be able to include these TWIG files from Drupal Views UI textarea - and we should be safe.

When talking about the "Custom" Views Field Plugin, it's more or less easily done, we just have to remove Xss::filterAdmin(...) from this:

/**
 * {@inheritdoc}
 */
public function render(ResultRow $values) {
  // Return the text, so the code never thinks the value is empty.
  return ViewsRenderPipelineMarkup::create(Xss::filterAdmin($this->options['alter']['text']));
}

But you did mention the field rewriting functionality in general - which might also be easy too, though I haven't studied that far yet. But in general we should be ok from any security issues since FieldPluginBase::renderText() already does the following (among other things):

if (!empty($alter['alter_text']) && $alter['text'] !== '') {
  $tokens = $this->getRenderTokens($alter);
  $value = $this->renderAltered($alter, $tokens);
  // $alter['text'] is entered through the views admin UI and will be safe
  // because the output of $this->renderAltered() is run through
  // Xss::filterAdmin().
  // @see \Drupal\views\Plugin\views\PluginBase::viewsTokenReplace()
  // @see \Drupal\Component\Utility\Xss::filterAdmin()
  $value_is_safe = TRUE;