-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot add to AllowedCssClasses after constructor, NullReferenceException #206
Comments
Perhaps we could initialize the HashSet to contain a single element "*" which means all if null was passed in the constructor. |
Or add boolean property Or add a boolean property that turns the whitelist into a blacklist, and set that to true if null was passed in the constructor. An empty blacklist = allow all. If possible, make the constructor overload that allows passing in a null collection deprecated in favor of a new method. |
Furthermore, I would like to point out that actually, an option to disallow all classes was never really needed. If someone wanted to do that, wouldn't they simply not add But it's too late for that now, unless you want to make the entire |
Suppose, while we're at it, it makes sense to suggest that the HashSet constructors use the override that includes a StringComparer (docs)? At the moment, the hashset is case-sensitive - is that intentional? |
@tiesont Absolutely. The current state also means that if you don't pass null in the constructor you can never go back to allowing all classes. So if we adopt the |
It's technically still a breaking change. If someone out there is doing checks like |
You're right. Then how about letting the getter return null if |
That eliminates any breaking changes, but results in confusing behavior. Devs would still run into NullReferenceExceptions until they fully understand that the value of The way I see it, there are two better options that avoid any breaking changes:
|
I like option 2 better, except for the blacklist part which I think is too confusing. Since the next release will be a major version update anyway, how about not deprecating |
I wonder, if you're considering removing |
Then some people (who relied on the current behavior) might not recognize that there was a breaking change (code still compiles and seemingly works, no exceptions thrown etc) when in fact the behavior was changed to the exact opposite. |
I see, that makes sense. Just keep in mind that it could be tricky to remove the constructor overload that accepted |
What if we removed the parameter from the constructor? This would introduce a runtime breaking change for everyone and a compile time breaking change for people who actually pass an argument (luckily it's the last one). |
That works, but wouldn't you want to add an overload that allows people to specify the allowed classes in the constructor, like you already can with attributes / elements ? |
I don't see a way to do this without running into the problem you described above where code will compile (and/or run without recompilation) but will behave differently. |
Option 2 wouldn't really help the constructor problem unless someone was explicitly specifying parameters (e.g. |
I think so, too. Here's more on versioning issues with optional parameters: https://haacked.com/archive/2010/08/10/versioning-issues-with-optional-arguments.aspx/ |
This throws a
NullReferenceException
:This is what the constructor of
HtmlSanitizer
currently does:Also,
AllowedCssClasses
doesn't have a public setter. Therefore, if you don't pass anyallowedCssClasses
into the constructor, the set will always benull
.I want to make a PR to fix this, but I'm not sure what the best way is to do it while retaining it's current behavior. When
AllowedCssClasses
isnull
, all classes are allowed. When it is empty, no classes are allowed. We can't simply make it fall back tonew HashSet<string>()
in the constructor, that would be a breaking change.Perhaps we should make it's setter public?
The text was updated successfully, but these errors were encountered: