I’ve been asked a few times about how you can add a rich text editor to Entity Forms or Web Forms on Power Apps Portals, and while I haven’t had the need to do this for a real implementation, I was curious to try it out. In the process, I found out about a setting I didn’t know existed that’s been around for at least a few years.

Before we get into the details, a shout out to Business Applications MVP Colin Vermander (@koolin_) for letting me bounce some ideas off of you to get this post done.

Not Hard, But Not As Simple As You Think

You’d think that adding a rich text editor to a Power Apps Portal Entity Form or Entity List shouldn’t be too hard. There are a lot of available What You See Is What You Get (WYSIWYG) Editors out there – in the past I’ve used both TinyMCE and CKEditor for various different types of projects. These editors generally make things pretty simple – point them at a <textarea> and they pretty much do the rest. Unfortunately, with Power Apps Portals, there is a gotcha: Request Validation.

Request Validation is an ASP.NET security feature that prevents the application from processing unencoded HTML submitted to the server. It’s designed to prevent script injection attacks. Since Power Apps Portals in an ASP.NET application where this default feature has not been turned off, if you try to submit raw HTML in one of the fields on your Entity Forms, the application will throw an error. This is what will happen if you simply apply a Rich Text Editor to a field on an Entity Form.

I’ve been aware of this issue since the Adxstudio days. However, back then since we controlled the ASP.NET application, we were able to turn this feature off when necessary. Once Microsoft moved the product to Software-as-a-Service, we no longer had that control. Or so I thought.

The Easy Fix

My intention with this blog post was to describe the solution I’ll present below. However, in putting it together, I discovered there is a way to disable Request Validation on Power Apps Portals, and it’s as easy as creating a Site Setting named DisableValidationWebTemplate with a value of true. As you’d expect, with the setting created, Request Validation will not take place and your rich text will be saved to the CDS database.

When I discovered the documentation, the first thing I did was look at the history in GitHub to see when that documentation was added. Turned out it was recently – early February 2020. I figured it was a new feature, so I didn’t feel too bad about not knowing about it. However, a bit of searching led me to find a reference to it from December 2017, so clearly it’s been around for a while. Another undocumented gem.

A Different Approach

You might be asking yourself why if there is already an easy solve for this, why would I bother providing another approach? The answer is because there is a reason why Request Validation exists, and if you can avoid turning it off for your entire site (which is what the Site Setting does), it’s something worth considering.

The alternative approach is to encode the data before it is sent to the web server for processing, then use a CDS plugin to decode the data so that it is saved as proper HTML.

In this example, I’ll use TinyMCE to demonstrate how this is possible. First, add a reference to TinyMCE in the Copy attribute of your page:

<script src="https://cdn.tiny.cloud/1/no-api-key/tinymce/5/tinymce.min.js" referrerpolicy="origin"></script>

Next, add the following to the Custom JavaScript field on your Entity Form:

$(document).ready(function() {
    $('#nh_description').hide().after('<textarea id="nh_description_rich">');
    tinymce.init({
        selector: '#nh_description_rich',
        init_instance_callback: function(editor) {
            editor.on('Change', function(e) {
                $('#nh_description').val(encodeURIComponent(tinymce.get('nh_description_rich').getContent()));
            });
        }
    });
});

In the above code, replace nh_description with the name of the field you want the rich text editor on. The JavaScript hides the original input, adds another <textarea> below the hidden one for the rich text editor, initializes TinyMCE on the new field, and any time the rich text editor changes, saves the encoded HTML to the original input.

Finally, register a plugin that fires on the create (or update, if your Entity Form is for editing) of your entity:

public void Execute(IServiceProvider serviceProvider)
{
    var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));

    var entity = context.InputParameters["Target"] as Entity;

    if (entity.Attributes.ContainsKey("nh_description"))
    {
        entity["nh_description"] = HttpUtility.UrlDecode(entity.GetAttributeValue<string>("nh_description")); ;
    }
}

This code simply decodes the value that was submitted so that you get back the original HTML. Again, replace nh_description with the name of the field you want the rich text editor on.

So while this technique a bit more work than disabling Request Validation, I’d argue it’s more secure. You’ll have to make the call whether the extra effort is worth it.

An Aside on Rich Text Editors for Power Apps Portals

In my example I used TinyMCE, but really you can use whichever editor you prefer. The Portal itself uses CKEditor (v4.6.2), however the references to the resources are not always included (for example, if your page template is a Web Template type, they only seem to be included when required by the platform for functionality like the legacy front-side editing). If you want to uses CKEditor, you might run into conflicts, so it something to consider when choosing a WYSIWYG editor.