HTML Encoding user inputted value and then running it through MarkdownSharp's Transform method will essentially re-encode text within code blocks.

[Google Code Exporter]

What steps will reproduce the problem?
1. Reference MarkdownSharp.dll in a web project.
2. Server.HtmlEncode(userInput)
3. markdown.Transform(encodedUserInput)
4. You will notice that the already encoded text gets re-encoded within code 
tags.

What is the expected output?
I would expect to be able to encode user input so that it can be safely stored 
in the database without having to worry about it getting pulled out and 
rendered incorrectly, at which point users visiting the site could become 
vulnerable to XSS attacks. I would then expect MarkdownSharp not to re-encode 
the values in the code blocks since they are already encoded, or at least offer 
a boolean switch to disable re-encoding of tags in code blocks.

What do you see instead?
MarkdownSharp re-encodes the code within the code tags that are rendered to the 
client.

Please provide any additional information below.
I have fixed the issue myself and added an option to the MarkdownSharp source 
that will disable the encoding of code blocks. I have attached the modified 
Markdown.cs file to this issue. Scan the file for _encodeCodeBlocks and you 
will find every area that I made changes to as that is the boolean option I 
added to change the behavior.

If this ever opens up in the future for contribution I would be interested.

Original issue reported on code.google.com by [e-mail] on 17 Mar 2011 at 8:17

Attachments:

• Markdown.cs

[Google Code Exporter]

Markdown allows arbitray HTML, so HtmlEncode before the transforming makes 
hardly any sense, whether in code blocks or not. For instance, if a user enters 
"bold" (which is valid in Markdown), HtmlEncoding would turn that into 
"<b>bold</b>", which is obviously not the desired result.

See my answer at 
http://meta.stackoverflow.com/questions/95821/markdownsharp-not-a-complete-rip-f
rom-stack-overflow/95861#95861 for more.

Original comment by [e-mail] on 12 Oct 2011 at 2:43

• Changed state: Invalid