Building HTML Applications for Microsoft Dynamics CRM – Security

Feb 22, 2016

Nikolay Sikorskyi

The first thing I want to point out is security issues with JavaScript. Using this language, anyone can see your code and mix it with custom scripts in the developer console in any browser. WebResources from Managed Solution can be easily changed and nothing remains protected. Actually, this is the main reason to reconsider using HTML and JavaScript. Unfortunately, until WebAssembly is released, there is no good alternative. Gathering libraries in one file with its subsequent minifying makes it harder to change or get business information. Nevertheless, it is not a cure.

Here, I want to propose to you a small workaround. As an example, let us use the basic CRM instance without custom handlers or ASP.NET endpoints – only WebResources and plugins. This should work for CRM on premise and online. Upload your application to this CRM instance with service libraries. If you are just thinking about building an application, I will review some existing libraries to connect CRM services in my next article.

Now, let us try to create a new account entity with only one description field:

Note: There are no classes in ECMA 5, but I will use this term to define functions used to create class instances.

In this case, “Entity” is a class for a CRM entity in Service Library and “service” is an object at least with a Create method. This method takes an Entity object, serializes it and sends to the server for creation. Callback and errorCallback are functions, which service will call after the async server operation.

Name attributes are default in basic CRM, but API allows us to create records without required fields. In this case, we will get a kind of “broken” record in CRM every time the application runs this piece of code.

The second part is the plugins. Let us create a new plugin with the PreCreate step for an account entity with the following code:

This plugin step should handle the creation of “broken” account entities and throw exceptions. After running it, the service library should handle fault response from the server and call errorCallback with an error message as a parameter:

errorCallback = function (error) {
eval(error);
}

Here, you can execute errors from a plugin as JavaScript code in runtime and get an alert on the page letting you know that everything is OK. If the callback function was called, it means that something went wrong, and you can log all parameters using the console or another logging approach.

This is only one example of the idea that will help you store some security code in the CRM code-behind. Of course, you could create a new entity for this process and set up security in such a way that only the Admin would have rights to create new records. Additionally, you could use its fields as parameters for the plugin’s execution. Remember, a user can still see this error coming from server. Using this approach with Web Api services is not a good idea because it is not stable and creates “broken” records.

Although this is not fit for all instances, for some key processes or licensing checks it is enough. Thus, you can start building your applications right now.
– May the CRM force be with you!