Skip to content

Conversation

@mworrell
Copy link
Member

@mworrell mworrell commented Jun 18, 2024

TODO:

  • Add path to the callback
  • Add tests

@mworrell mworrell marked this pull request as draft June 19, 2024 19:11
@mworrell mworrell marked this pull request as ready for review October 22, 2025 16:19
@mworrell mworrell requested a review from mmzeeman October 22, 2025 16:19
@mworrell mworrell self-assigned this Oct 22, 2025
@mworrell
Copy link
Member Author

@mmzeeman I had two questions for the 'property' sanitize callback.

  1. Should we pass the raw data, that is before our own sanitization?
  2. Should we pass more data, maybe the path to the property?

@mmzeeman
Copy link
Member

How flexible should it be? Do you want to have multiple sanitizers for different paths? Or a simpler one-sanitizer-fits-all approach?

@pasqu4le
Copy link

Should we pass the raw data, that is before our own sanitization?

Do you want to make it possible to avoid/skip the built-in sanitization? 🤔

If not (which I guess is wiser), then I'd say that it's more convenient to only pass the pre-sanitised data, which is going to happen anyway, and allow custom additional secondary sanitization.

Otherwise, I'd only pass the raw data instead (as it's always possible to call the built-in sanitizer first).

Should we pass more data, maybe the path to the property?

I think that would be nice, IMO this could be used to add context-specific sanitization.

E.g. one might want to store some CSS in resource properties and do CSS-sanitization, but not necessarily apply it to all fields.

@mworrell mworrell changed the title WIP: z_html: add property filter callback z_html: add property filter callback Oct 23, 2025
@mworrell
Copy link
Member Author

Do you want to make it possible to avoid/skip the built-in sanitization? 🤔

If not (which I guess is wiser), then I'd say that it's more convenient to only pass the pre-sanitised data, which is going to happen anyway, and allow custom additional secondary sanitization.

Good thinking, from a security perspective I indeed would prefer to ensure that data is always sanitized.

Problem might be that there is some custom sanitization happening that would be incompatible with the default sanitization.

That is why I thought to pass a sanitized key and the content as-is. If the custom code then doesn't do anything we can perform our own sanitization.

Should we pass more data, maybe the path to the property?
I think that would be nice, IMO this could be used to add context-specific sanitization.

Good, I will check if I can keep the path, and then we can pass that.

E.g. one might want to store some CSS in resource properties and do CSS-sanitization, but not necessarily apply it to all fields.

Indeed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants