Traditionally as a SharePoint developer or designer your skills and toolkit were quite different from those of a standard web developer. While that used to be essential to your success, in today’s web-centric world as you transition your skills it might mean you overlook the obvious when troubleshooting. Recently I was helping a developer colleague resolve one of those eponymous “Sorry, something went wrong” messages that SharePoint 2013/2016 is so famous for, when it drove home this point: Always start with the web-dev basics!
In the old school approach as a SharePoint dev whenever there is an error in my solution I almost always start with the ULS logs. But in this case SharePoint isn’t giving anything away for free, no correlation id is offered for us to look up.
My colleague and I are about to launch into SharePoint server-side ninja debugging but something makes us stop and we take a step back to re-consider our approach.
Don’t be hasty, perhaps there is a client-side issue, we say to ourselves. Ah yes, time for every web developer’s true friend, the F12 developer tools! Duh-da-da-dah!
Now we are getting somewhere: The browser threw a couple of SEC7112 warning on ~/layouts/15/AccessDenied.aspx:
HTML1300: Navigation occurred.
SEC7112: Script from http%3A%2F%2FXXXXX/sites/Picasso/_layouts/15/AccessDenied.aspx?Source=http%3A%2F%2FXXXXX%3A81%2Fsites%2FPicasso%2F%5Fcatalogs%2Fmasterpage%2Fdisplay%20templates%2Ffilters%2FXXXXX%5Ffilter%5Fmultivalue%5Fmultilang%2Ejs%3Fctag%3D444%24%2415%2E0%2E4753%2E1000&Type=item&name=7682e984%2D9fa9%2D4945%2Db6e4%2D1e5152a1ce1d&listItemId=360 was blocked due to mime type mismatch
Yeah, but what is a “SEC7112: Script from … was blocked due to MIME type mismatch” error, you might ask? MSDN Library provides a succinct answer in its Web Development series under Internet Explorer, HTML and DOM compatibility changes: Reducing MIME type security risks:
The script and styleSheet elements will reject responses with incorrect MIME types if the server sends the response header “X-Content-Type-Options: nosniff”. This is a security feature that helps prevent attacks based on MIME-type confusion.
In layperson terms, Internet Explorer requested a script or stylesheet resource from SharePoint as part of fulfilling the results.aspx page, but the response from SharePoint did not have a corresponding acceptable MIME type, and SharePoint sent the response header X-Content-Type-Options: nosniff, so the browser blocked the response. The MSDN article lists the acceptable MIME types for each of a script of stylesheet resource, for example:
- txt/css for a stylesheet resource
- etc (several other MIME types) for a script resource
Hmmm, yeah right, so what does that have to do with loading ~/layouts/15/AccessDenied.aspx? And why was the browser requesting, or more likely receiving, an AccessDenied.aspx response from SharePoint when it was supposed to be loading results.aspx?
We haven’t gotten to the bottom of this story yet!
Looking in more detail at the AccessDenied.aspx page URL we see that it provides an encoded URL query string parameter, the URI that causes the denied access:
Time to call on another of the F12 dev tools, the Network tab, which shows every single page and resource request and response between the browser and the server to fulfill the original page navigation:
HTTP 302 Found means that a page or resource is temporarily not at the URL in the original request but will be found at another URL indicated in the response headers.
Let’s dig a bit deeper and look at the Request Headers:
Text version of those headers:
|Request||GET /sites/Picasso/_catalogs/masterpage/display%20templates/filters/XXXX_filter_multivalue_multilang.js?ctag=444$$15.0.4753.1000 HTTP/1.1|
|User-Agent||Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko|
And looking at the Response Headers:
Text version of those headers:
|Response||HTTP/1.1 302 Found|
|Date||Tue, 18 Oct 2016 20:42:01 GMT|
Note the response header X-Content-Type-Options with the value nosniff as expected given the SEC7112 warning. But why the HTTP 302 Found response code and the redirect to AccessDenied.aspx? We are still puzzled by all these warnings and response codes.
The next step seems to be to directly request the script file and see if we can retrieve it.
Well we knew already that from the first console warning, sort of, but now the situation is clearer: The original Sorry, something went wrong message is because we are not permitted to retrieve one of the display templates (script resources), XXXX_filter_multivalue_multilang.js, referenced on the main page results.aspx.
Let’s have a look at this file in the SharePoint Master Page Gallery library. First we check the permissions on the file and its parent library and site. Those all check out, access is granted to Restricted Reader and our current logged-in to SharePoint account / AD user / AD group is a member of this SharePoint security group.
[Insert image: permissions]
Second we check that this display template has at least one published major version, since Restricted Readers won’t see draft versions.
Bingo! So there we have it. No published major version means our test user account which is only in Restricted Readers can’t access the file, hence AccessDenied.aspx was returned by SharePoint.
Here in summary is the chain of events when we browser to results.aspx:
- Browser requests results.aspx page with various css and script elements
- Browser requests each of the css and script resources, including XXXX_filter_multivalue_multilang.js
- SharePoint receives the script resource request and applies security trimming
- There are no published major versions of the script resource
- Current user as a member of Restricted Readers does not have permission to access a file with no published major version
- SharePoint responds with the AccessDenied.aspx page and an HTTP 302 Found status code to indicate that it is a temporary redirect, and MIME type text/html
- Browser throws a SEC 7112 warning because the MIME type is not correct
- In lieu of the missing display template results.aspx page displays the eponymous message Sorry, something went wrong
Thankfully it is a simple fix, we publish a major version of the script file:
And now the search results page loads correctly, including the missing search refiners:
And the F12 Developer Tools tabs are clean, in the Console tab there are no more SEC7112 errors, and in the Network tab there are no more HTTP 302 response codes.
In summary, in today’s day and age as a SharePoint developer when you are troubleshooting web page issues it is essential to know how to effectively use the browser F12 developer tools as your first point of discovery and investigation.
Happy developer happy business client!