[FIXED] [#1395] [4.2.0] X-Content-Type-Options: nosniff has broken EXT v3

[PeterParsonage]

We have been forced to add the option nosniff to the site configuration for security reasons. This has immediately broken the EXT stuff.

Refused to execute script from 'http:/..../extent/extent-init-js/ext.axd?b14....' because its MIME type ('application/json') is not executable, and strict MIME type checking is enabled.

I'm really hoping someone here has a simple work around for this.

Crossing fingers... Peter

[fabricio.murta]

Hello @PeterParsonage!

We'll have to do a little more research in this nosniff content type, but up front, I can tell you that Ext.NET server side responses are heavily based on json representations of the objects, like pages for example.

Can you tell us the minimal requirements of an Ext.NET page to reproduce the issue? How exactly are you setting this content type on your project? We would appreciate directions on reproducing the issue our side so we can check and provide you a better feedback about this, whether this is a limitation and design requirement, or if there are some settings you can change in order to make Ext.NET work with this approach.

Looking forward for your feedback!

[PeterParsonage]

<system.webServer>   
   <httpProtocol>
      <customHeaders>
        <add name="Strict-Transport-Security" value="max-age=31536000" />
        <add name="X-Content-Type-Options" value="nosniff" />
        <add name="X-Frame-Options" value="SAMEORIGIN" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>

This should be all you need to reproduce the error. It happens on every ext page we have and they were all working before this web.config change.

[fabricio.murta]

Hello Peter!

You're right, this is a bug! Or at least an inconsistency. The responses Ext.NET provides are entitled as application/json when the actual content is a javascript block!

But we have, yes, some situations where the response is just a json block, so we can't just rename the content type to application/javascript without a deeper analysis on how to implement this without breaking other parts of the code.

It is interesting how this issue was only raised now. We've logged it under #1395 and just applied a test fix for you to verify on your side. We just fixed the init script handling and it should work for you at least on most pages. But you will have to specify the following setting on your extnet tag (in your Web.config file):

initScriptMode="LinkedJS"

Please let us know whether this works for you, we've fixed it in both Ext.NET v3 (revision 6802) and v4 (master branch on github). I believe that some direct events and dynamic methods may trigger this error in some circumstances, but we will have to wait and see. In some situations I believe it would be possible to fix without any changes to Ext.NET at all so let us know as soon as you see another issue related to this content-type inconsistencies.

Looking forward for your feedback!

[PeterParsonage]

Do I need to pull any new code or is the config change all I need to try?

[fabricio.murta]

You need to build Ext.NET from latest SVN sources (ensure you got revision 6802 or higher), and then from that fresh build, the setting in Web.config. It should already have a line that looks like:

<extnet theme="Triton" licenseKey="** Ext.NET LICENSE KEY HERE **" initScriptMode="Linked" />

You'll have to change (or add) the initScriptMode to be LinkedJS. Something like this:

<extnet theme="Triton" licenseKey="** Ext.NET LICENSE KEY HERE **" initScriptMode="LinkedJS" />

And now the real check up will take place, as you might have some pages that will still trigger the error (depending on what kind of dynamic content you load to them). And for those, we'll have to analyze case by case. I'm confident that at least most of the remaining possible issues will be able to be resolved without further changes in Ext.NET code.

Hope this helps!

[fabricio.murta]

Hello! If you have not tried this yet, we've just updated again SVN to revision 6803. There was a problem with the first "fix" where init script mode as Linked wasn't working at all.

Important, the LinkedJS will only work as intended when it is set in Web.config. The idea here is to check if this works without implying on other code to break and make it the default. A possibility is that this change will only make it at full in Ext.NET 4.

Hope to get your feedback soon!