D365 Portals : X-Content-Type-Options Header

In an earlier post I provided a few of options for dealing with JavaScript code in your D365 portals. The second of those options was to modify the extension of the file that is attached to the Web File Note so it isn’t blocked as an attachment.

With a recent upgrade to the portal it appears that Microsoft have now closed the door on that particular option and for good (security) reasons. They have now added the X-Content-Type-Options header to the response with a setting of nosniff. This means that when the browser detects a difference between the file extension and the MIME type then the browser generates an error and the script is not loaded.

This means that in order to use custom JavaScript files in your D365 portals you are left with either option #1 or option #3 from my previous post, or use a CDN.

Advertisements

D365 – Field Service – Debugging Booking Rules

Booking Rules in D365 are generated as Web Resources (JavaScript) to show warning or error messages to the scheduler. The problem with debugging these web resources is that the files are loaded dynamically which makes them a little harder to debug. When you have complex or a large number of booking rules you have a few options to assist you with debugging.

  • console.log – this is the most basic option but allows you to write out values to the debug console of the browser. This can give you some information may not pinpoint the exact line were an issue is occurring.
  • debugger statement – this will cause your web resource to load into the dev tools of the browser and stop on the line where the statement exists. This at least allows you to continue on with debugging but you need to remember to remove it before you publish the resource into a production environment.
  • sourceURL comment – if you place the following comment at the end of your script file – after the closing curly brace – the file will then show in the sources tab.
//# sourceURL=filename.js

You can replace filename.js with any filename you like, e.g. BookingRules.js. When you browse your Sources in the Dev Tools you will find the file and be able to put in breakpoints as required. You will need to force the booking rules to run at least once for the file to be loaded. The other good point about this technique is that you don’t need to remove the comment for the file when its moved to a production environment.

This works for Chrome, Firefox and the new Chromium Edge browsers.

D365 Portals – tokenhtml

If you need to refresh the __RequestVerificationToken on your page, this is stored as a hidden input field but can be generated on demand by loading /_layout/tokenhtml.

In my case, I apply the token to a form posting to ensure the request is valid.

    $("#antiforgerytoken").load("/_layout/tokenhtml", function() {
        console.log("tokenhtml loaded");
        $("form>input[name='__RequestVerificationToken']").val($("div#antiforgerytoken>input[name='__RequestVerificationToken']").val());
});

Using Javascript to disable a button in ASP.NET

How do we stop those trigger happy web users who feel the need to press buttons more than once. One way is to disable/change the button on the first click. All that is required is a couple of simple lines of code to make this happen. In my Page_Load event I have the following;

if (!IsPostBack)
{
    MyASPNetButton.Attributes.Add("onclick", "this.value='Please wait...'; this.disabled=true;" +      Page.ClientScript.GetPostBackEventReference(MyASPNetButton, "").ToString());
}

IE Compatibility View

Having done some intensive research over the last couple of days to define exactly what happens when you set your IE browser to Compatibility View I thought it was worth noting a few things down.

  • IE uses Compatibility View to let website developers/administrators define how a website is displayed regardless of the version of IE being used. This is because MS are moving away from their bespoke CSS implementations, used for < IE7, to the more recognised W3C version.
  • The Compatibility View also affects the level of support applied to JavaScript code as functionality will change between versions of IE.
  • By default, any IE user running in the Local Intranet Security zone is automatically forced into Compatibility View. However, this option can be changed either by a user with sufficient permissions or Group Policy.
  • There is no way to programmatically stop users from running the site in Compatibility View. Adding the <meta> tag correctly disables the option from the Tools menu but the site can still be forced into Compatibility View either by:
    • Using the default Compatibility View settings and running in the Local Intranet security zone
    • Adding the site to the Compatibility View settings (this is a separate option to the Compatibility View switch in the Tools menu).

These are some of the useful links I have found whilst scouring the web for relevant information:

Getting the Latitude and Longitude from Bing maps

Pinpoint an exact spot.
To get the Latitude and Longitude from Bing maps you should centre the map on your point of interest, then do either of the following:
  1. Type javascript:map.GetCenter() in the address bar of IE and then hit ENTER. Your map will change to a page containing the Latitude and Longitude.
  2. In Firefox, using Firebug go to the Script tab and the in the right hand (Watch) pane enter javascript:map.GetCenter() into the New Expression field and hit ENTER. (see below)