Can't use Web App Builder on new Portal installation

[CassandraFollett]

I've recently installed Portal onto a new server that is federated with a separate GIS Server. The server environment is a "default deny" type of environment which I will come back to in a moment after describing the issue. 

If one tries to create a new app using Web App Builder (From the Portal page under My Content), as soon as one fills the title tags and summary and clicks submit, it first shows the loading screen for the Web App Builder for a very brief period and then redirects to sign the user out automatically instead. 

If I have Developer Tools logging this while running, firstly I see the following warning in Chrome before even starting up web app builder (using Chrome) when I log in and go to My Content:

Refused to execute script from 'https://[website URL]/portal/sharing/proxy?https://[GIS Server Machine Name]:6443/arcgis/admin/data/findItems?managed=true&f=json&token=[Token]&callback=dojo.io.script.jsonp_dojoIoScript1._jsonpCallback' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.

When I click through to create a new Web App, I get this similar warning in the console:

Refused to execute script from 'https://[Website_URL]/portal/sharing/rest/portals/self?f=json&token=[Token]&callback=dojo_request_sc...' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.

Anyone run into this issue themselves and have hints on how to proceed? 

My thought is that it may be related to pulling/running external scripts... The ArcGIS Server machine is limited from  the internet with only whitelisted ports, for instance. Aside from that, I did notice that Web App Builder uses self-signed certificates, which may be an issue as well? Before speculating I wanted to see if anyone else has input.

I did find a similar question here: ArcGIS Web Application Template / Portal Issue  

[RandallWilliams]

The only time I've seen this is when admins set the X-Content-Type-Options:nosniff header at the web tier. This option is supported post 10.6.

[CassandraFollett]

Randall, it's the perspective of the folks who handle the web tier that the nosniff header is valuable to keep set for cybersecurity reasons. I'm inclined to agree. I am disappointed that this would be in a new version rather than a patch as this means that we're unable to use this feature until summer 2018. Thank you for your insight in helping figuring out what the issue was. 

[RandallWilliams]

Hi Cassandra,

I can appreciate the sentiment and provide a little context, for what it's worth.

In order to use the nosniff option, certain values for content-type headers must be specified for nosniff to work properly (the content-type must be executable).  Esri was one of the first companies to adopt a RESTful approach, and many of the content-type values we should use were not available at that time. They were correct at the time we implemented our REST-ful approach, but are no longer correct for modern web browsers. 

We are updating our code to use these values.  A challenge we face is that some of our clients and SDKs (.Net Runtime notably) look for the old content-type values. They are going to update their next versions.  Also, customers who have clients written in .Net may need to use an option we are putting in the software to go back to the old content-type values. 

It is on our roadmap to move to nosniff at future release once we have all of our products using the modern content-type values.  

[CassandraFollett]

This context is well appreciated and clears up some confusion on my end. Thanks again, Randall.