Swagger Validation Badge always displays RED error

I always get a RED error logo for the Swagger Validation Badge in the Developer Portal on Tyk Cloud.

However, my imported Swagger documentation always validates as GREEN with no errors when I submit it directly to the Swagger validator like this:

It seems that the Tyk Developer Portal would be doing something similar underneath. Any idea what would be causing the RED error logo to appear?

And when I click on the RED error logo, I get this message:

{“schemaValidationMessages”:[{“level”:“error”,“message”:“Can’t read from file /portal/apis/597a8c6083497f0001271667/documentation/raw”}]}

So it appears that the base path (https://xxx.cloud.tyk.io) is not being prepended to /portal/apis/597a8c6083497f0001271667/documentation/raw. Any idea why that would happen?

It might be a CORS error. Can you show the output of your chrome (or Firefox) developer console?

There doesn’t appear to be a CORS errror, but here is what I am seeing in the various tabs in the Chrome developer console:

  1. In the Console tab, this message appears after navigating to the documentation page in the Tyk Developer Portal:

    swagger not loaded yet (index):243

  2. In the Source tab, this code appears when I click on (index):243

     var isSwaggerJsonLoaded = function isSwaggerJsonLoaded() {
       if(!!ui.spec().toJSON().resolved) {
         **strong text**
       } else {
         console.log('swagger not loaded yet');  // line 243
         setTimeout(function () {isSwaggerJsonLoaded()},1000);
  3. In the Network tab, it appears that the Request URL is not formed properly. The url parameter does not have the base address (https://xxx.cloud.tyk.io):

    Request URL:https://online.swagger.io/validator?url=/portal/apis/xxxxxxxxxxxxxxxxxxxxxx/documentation/raw

  4. In the Security tab, these origins are identified:

    Main Origin: https://xxx.cloud.tyk.io
    Secure Origins: https://online.swagger.io
    Unknown/Canceled: https://ajax.googleapis.com, https://fonts.googleapis.com, https://fonts.gstatic.com

Looks like it is a bug in our new template, I’ve raised an issue: