Ticket #4708 (closed New Feature: fixed)

Opened 4 months ago

Last modified 4 months ago

Missing configuration from pre-3.0: HtmlEncodeOutput

Reported by: jensenbox Owned by: garry.yao
Priority: Normal Milestone: CKEditor 3.1
Component: Core : Output Data Version: SVN (CKEditor)
Keywords: Confirmed Review+ Cc: christian@…

Description

It would appear that the 3.0.1 build does not contain a very important configuration for ASP.NET (and ASP.NET MVC) - the ability to encode the HTML prior to the form submission.

ASP.NET balks at any content being submitted that contains a < and a > with the message "A potentially dangerous Request.Form value was detected from the client"

This functionality was added in #1266 in a prior release.

It is possible to circumvent the issue with setting a "ValidateInput=false" setting however this is set either at the page level or the method level. Ideally this would be as granular as the field in question but those facilities do not exist at this time.

The ideal situation would be to have CKeditor pre-encode the content before submission to the server.

Workarounds available:

Attachments

4708.patch Download (1.3 KB) - added by garry.yao 4 months ago.

Change History

Changed 4 months ago by fredck

  • keywords Confirmed added
  • type changed from Bug to New Feature
  • milestone set to CKEditor 3.1

Changed 4 months ago by garry.yao

Changed 4 months ago by garry.yao

  • keywords Review? added
  • owner set to garry.yao
  • status changed from new to assigned

Ticket Test added at :
 http://ckeditor.t/tt/4708/1.html.

Changed 4 months ago by fredck

  • keywords Review+ added; Review? removed

Please transform the new htmlEncodeOutput setting in a documentation only thing when committing.

Changed 4 months ago by garry.yao

  • status changed from assigned to closed
  • resolution set to fixed

Fixed with [4586] and [4587] at 3.1.x branch.

Changed 4 months ago by alfonsoml

An additional comment:

I think that this setting was the cause of previous bug reports (in asp.net environments, that's the clue) that when pressing the back button of the browser, FCKeditor showed in design mode the html code.

My thoughts about this problem is that the browser was reloading the latest value of the textarea, and that was the html-encoded value, so this configuration should be paired with the requirement that the original input is also html-encoded (which should be easy to handle if the asp.net server side integration was provided, but it seems that it still isn't ready and people are doing it in their own way).

Just some thoughts...

Note: See TracTickets for help on using tickets.