Even though some people debate the effectiveness of the request validation that comes built into ASP.NET, you get it for free so it makes sense to use it. So when working with a HTML editor which is going to be posting back “potentially dangerous HTML” you’ll probably want to use an editor which lets you encode its content, like TinyMCE does via its XML encoding. If you’re interested and haven’t used its XML encoding before then you can read more about it here) in order to avoid disabling request validation.
Normally this all works well, however it seems that when you throw TinyMCE’s fullpage plugin into the mix things start to go a little awry. The fullpage plugin lets you do exactly what its name suggests – edit a full page of HTML, including doctype declarations and all the tags you’d expect with a full HTML page versus a snippet of HTML as you’re often dealing with in a typical CMS scenario. As soon as I’ve got the fullpage plugin in the mix then the XML encoding option seems to be ignored.
Here’s some snippets from a couple of quick fiddler debug requests:
Firstly, without the fullpage plugin, you can see encoding such as %26lt in affect:
Next, I add the fullpage plugin back in, and bam:
Obviously the HTML is different as the second example, but otherwise the only difference is the addition of the plugin.
Right now, I need a bit more time to do a little more testing to confirm that I’ve not overlooked anything obvious, which is the reason of this post – to harness the power of the Internets! Come forth you .NET TinyMCE gurus, and tell me: am I missing something obvious here, or have I stumbled onto a bug?
Tags: ASP.NET, Web Development