This article is for jsConnect V2 only. It is highly recommended that you upgrade to the much more robust jsConnect V3 which solves these types of connectivity issues. Please see Upgrading jsConnect To Version 3.
In the past web browsers and web servers were pretty lax about small details in document headers. If your browser requested a JSON document from a web server, the webserver might send back the document but with Content-Type headers set to 'text' instead of JSON, since JSON is a text document. For example: Content-Type: text/html; charset=UTF-8
Because browsers knew that the response headers coming from servers were not necessarily reliable, browsers employed a technique of reading a sample of the content of a file (or 'sniffing') a document to try to determine what kind of document it really was and how it should be treated.
Recently browsers, web servers and server administrators are tightening things up -- which can cause problems with some set ups for jsConnect.
As part of the jsConnect workflow, a Vanilla Forum will call the authenticating server through AJAX expecting a JSONP response. In the past servers would send this JSONP response with a Content-Type: text/html and the browser would 'sniff' it to determine that it was not HTML. Server administrators, as part of routine tightening of security, can change a setting in their web server to send a X-Content-Type-Options: nosniff with all responses telling browsers to strictly apply the Content-Type sent in the header. Now the AJAX call will fail.
The fix: Update your jsConnect library from one of our Github libraries, depending on the programming language you use. If not, in your script that responds to the callback from Vanilla add the proper headers: Content-Type: application/javascript; charset=utf-8