Closed ardove closed 2 years ago
Your use case is still possible, see https://github.com/mganss/HtmlSanitizer/issues/220#issuecomment-1009808628.
Hm, you're right. I saw another one of my unit tests fail and assumed it was a problem with this change, but may be a separate problem.
I'm several major versions behind and attempting to upgrade to the latest version of HtmlSanitizer. Admittedly, it's annoying that we're so far back, but I've only inherited the library, so it's been out of my control for a while.
I used to be able to construct a new HtmlSanitizer with empty arrays to produce an HtmlSanitizer that didn't allow anything. That appears to be impossible now as a result of the changes in the following issue and the related discussion. https://github.com/mganss/HtmlSanitizer/issues/220 https://github.com/mganss/HtmlSanitizer/discussions/314
We use this in a WebApi modules as a safety net for our development teams to help them build correct, secure applications by default, rather than allowing arbitrary html through to places where it shouldn't be allowed. By using attributes on WebApi controllers, they are able to explicitly allow specific tags, rather than the "default set" configured in this library, but now, we can't support that.
For the interim, I guess my only option is to downgrade this library. Looking forward to your reply.
I was able to get this to work in 6.0.453. The break occurs in 7.0.473. I appreciate the update in major version to indicate the change, but I think there should still be a way to support this use case.