Another little, but hopefully useful, quick tip to ease Dynamics portal deployment pains.

I used to get a load of errors when using the Portal Data Mover in the (awesome) XrmToolBox to move portal config from dev to test, specifically when moving records from the Web Files entity.

The problem was that, by default, files with a .js extensions are blocked when being loaded to Notes in D365, which is where the binary content of all js files are stored.

This unfortunately means when you migrate portal configuration from one instance to another (e.g. dev to test), the Web File annotations fail to load.

To rectify this:

  1. In your target CRM instance, navigate to Settings > System Settings > General Tab > Set blocked file extensions for attachments
  2. Remove “.js;” from the delimited list of blocked extensions

D365_SystemSettings_AllowJS

Of course, you should review whether allowing the upload of JavaScript files is safe for your organisation: If a portal user or rogue employee were to upload some js to an attachment would there be a potential issue? Do you need to add additional checks/whitelisting on user upload? Do you do any post-upload precessing of attachments that could sidetrack the Dynamics security precautions?

Some thoughts on this to perhaps ease those worried about turning off an out of box security measure:

  • The block is only enforced on initial upload. Re-enabling the block won’t purge js files already in your system. So you could always have a deployment task to disable the block, run the migration/deployment and then re-enable.
  • From my, admittedly limited, testing both portals, and Dynamics in general, seem quite robust in its handling of injected code and potential xss attacks. But of course it does also depend on whatever custom processing you do on these files thereafter.
  • An alternative for the very security conscious is to leave the block in place and have all JavaScript stored either in (a) the “Advanced” section of a Web Page or (b) a Web Template which can be consumed by another template as required. Given the choice of these two, I’d almost always go for the latter as it at least gives you the ability for code reuse – I’m not a fan of the former unless it is incredibly page specific or its a POC or hatchet job (which obviously none of us have ever done, ever)
  • Best I think though, and this is normally my preferred route if feasible, try not to store any js files or libraries in CRM at all. The development, deployment and testing paths unfortunately leave a lot to be desired so why bother. Instead, host your js in a CDN and reference that in your Web Templates so you can develop and test in a more traditional way without the all too regular “copy and paste” or “upload and test” scenarios we see in Dynamics development.

Hit me with a comment if you have questions or other/better alternatives! 🙂