-
Notifications
You must be signed in to change notification settings - Fork 225
Option to bypass GetContent HTML encoding in TagHelper #643
Comments
Thanks for the write up. Here's a gist I did to demonstrate the issue too: https://gist.github.com/DamianEdwards/d57810d28d977058e702 |
Yeah this is a layering issue. The Razor parser is emitting code that always evaluates the content inside a Tag Helper as a Razor expression, and thus writes it out that way, which always HTML encodes. I think we need to either:
|
@DamianEdwards suggestion 1 is similar to letting tag helpers declare authors should treat the element content like a bound For suggestion 2, note one issue with concepts such as "encoded and unencoded result of the expression" is the mix of scopes in a Separately, binding to a |
@dougbu why would suggestion 1 require tooling support? It's just changing the behavior of contained expressions, not literal content. |
Because users HTML encode literal content when they're typing in an HTML context. |
Example? |
|
@dougbu ah yes, of course. A tooling feature isn't a huge deal, and frankly we could ship a version without it. This will be applicable only to very particular Tag Helpers. Let's chat about it in person this week. |
@DamianEdwards and I worked through the implications of this issue and decided that in order to fix this we'll add an overload to
Both parts need the encoder. |
@NTaylorMullen please loop in @Eilon on these conversations or talk to me about it tomorrow. What you're suggesting will be incorrect in at least some cases e.g. literal text between the start and end tags. Note as well that this approach assumes all encoding is deferred until |
@dougbu I think you misunderstood the suggestion.
The suggested approach does not defer all encoding. Anything that is |
Huh? It assumes everything inside that The approach also assumes literal strings contain neither characters that are already encoded |
Oh, I wouldn't consider that deferred. That's just how Razor has always worked. Anything after
It's just Razor, it doesn't make any assumptions, I'm not seeing how this is different than classic Razor. If you want your stuff to not be encoded and its a string, wrap it in |
@dougbu please also add to this bug the final decisions that were made when you met with @DamianEdwards and @NTaylorMullen so that we can track those here. |
@DamianEdwards, @NTaylorMullen and I talked about this before the ⛄🎁Days of Quietude🎆🎉 As I remember it, we all recognize literal text in the element's body involves lots of odd cases e.g. when the So we'll go with what @NTaylorMullen described above:
Ideally we'd also have Tooling support of some kind -- something to let the But I won't be doing the work this year and this extends the |
I'm cool with this. @DamianEdwards please confirm. |
👍 |
…ding an `HtmlEncoder` - #643 - change is viral and requires an update to `RazorPage.StartTagHelperWritingScope()` - note `HtmlEncoder`s used elsewhere e.g. in other `RazorPage` instances are unaffected WIP: - new tests of the new `TagHelperOutput` methods yet - test do not pass a non-`null` `HtmlEncoder` into `TagHelperScopeManager.Begin()` Nit: remove unused `using`s in files I had open
- aspnet/Razor#643 part 2 - add `HtmlEncoder` parameter to `RazorPage.StartTagHelperWritingScope()` - note `HtmlEncoder`s used elsewhere e.g. in other `RazorPage` instances are unaffected Also simplify scope management, removing bizarre assertion when user does something odd. - see code comments to reviewers about other options here. Loads of test fallout though this is a WIP: Not yet testing out the new feature.
…ding an `HtmlEncoder` - #643 - change is viral and requires an update to `RazorPage.StartTagHelperWritingScope()` - note `HtmlEncoder`s used elsewhere e.g. in other `RazorPage` instances are unaffected WIP: - new tests of the new `TagHelperOutput` methods yet - test do not pass a non-`null` `HtmlEncoder` into `TagHelperScopeManager.Begin()` Nit: remove unused `using`s in files I had open
- aspnet/Razor#643 part 2 - add `HtmlEncoder` parameter to `RazorPage.StartTagHelperWritingScope()` - note `HtmlEncoder`s used elsewhere e.g. in other `RazorPage` instances are unaffected Also simplify scope management, removing bizarre assertion when user does something odd. - see code comments to reviewers about other options here. Loads of test fallout though this is a WIP: Not yet testing out the new feature.
…HtmlEncoder` - #643 part 1 - change is viral and requires an update to `RazorPage.StartTagHelperWritingScope()` - memoize `GetChildContentAsync()` per-encoder - update generation tests to match and to test new behaviour - note `HtmlEncoder`s used elsewhere e.g. in other `RazorPage` instances are unaffected Add `NullHtmlEncoder` Nits: - generally clean up affected doc comments and make them more consistent - remove unused `using`s in files I had open
- aspnet/Razor#643 part 2: react to aspnet/Razor#653 - change test calls and delegates to include new parameter - add tests specifically of the new feature - add tag helpers using new feature to `TagHelpersTest` functional test - note `HtmlEncoder`s used elsewhere e.g. in other `RazorPage` instances are unaffected - i.e. changing one `RazorPage.HtmlEncoder` property only affects C# expressions in that page Also simplify scope management, removing bizarre assertion when user does something odd. nits: - correct `// Act` and `// Act & Assert` content - remove #YOLO wrapping
The way to get the raw content is like this:
|
The current implementation of
TagHelperContent.GetContent
automatically HTML encodes when called from within theTagHelper
implementation. Using Dave Paquette's implementation of MarkdownTaghelper
, I am able to reproduce the unexpected behavior of premature encoding.Implementation
Input
### Features\r\n\r\n* API namespace cleanup for tag helpers ([#578](https://github.com/aspnet/Razor/issues/578))\r\n* Refactor WriteAttribute API surface. ([#177](https://github.com/aspnet/Razor/issues/177))\r\n\r\n### Bugs Fixed\r\n\r\n* Multiple TagHelpers targeting same element cannot effectively communicate to children. ([#571](https://github.com/aspnet/Razor/issues/571))\r\n* Compilation error within tag attribute shows generated code instead of markup ([#569](https://github.com/aspnet/Razor/issues/569))\r\n* Specifying `RestrictChildren` and empty `HtmlTargetElement` results in an error ([#562](https://github.com/aspnet/Razor/issues/562))\r\n* `TreeStructureChanged` marked as `true` when whitespace is added to a page with `TagHelper`s ([#553](https://github.com/aspnet/Razor/issues/553))\r\n* Expose `FilePath` on `MappingLocation` to let Razor editor know mapping origination. ([#552](https://github.com/aspnet/Razor/issues/552))\r\n\r\n
Expected
Actual
Proposed Solution
I expect to be able to pull the exact contents of the tag element, even if there is content that is potentially unsafe at runtime. The responsibility of HTML encoding should be left up to the
TagHelper
developer.http://www.khalidabuhakmeh.com/asp-net-5-mvc-6-taghelpers-and-the-cake
The text was updated successfully, but these errors were encountered: