Swagger-ui: Way to disable validator?

[hlubovac]

I've seen Known Issues and the current support for only "url" and "spec" settings. I'm not sure what the "spec" value is supposed to be, but - anyway - I'm not able to load an existing, non-public swagger-2 document (I'm also not sure if loading a v2 spec is a valid expectation), and, based on the feedback within the UI, I'm guessing it might be because the script isn't getting passed that specs-validation step.

I see it working for petstore; the only thing I changed within index.html is the url value. Tried both over http:// and file:///.

Thanks.

[hlubovac]

Strange, but this works - however, randomly/occasionally. What I noticed: when browser's F12 dev tools (or, console) is open/enabled, then this won't work, no matter what. When that tool/console is not present, then this works (not every time, though). I don't know if this is related or a coincidence, but I can't use those client tools to troubleshoot.

[hlubovac]

I just noticed: I still get validator's red "error" icon on the bottom of the UI - so, UI not rendering might not be related to validation failing. Specs url is still local.

[ddelay]

I have the Swagger UI distribution deployed to an internal HTTP server (inside a company firewall). Since upgrading to Swagger UI 3.0.x, I've seen the same behavior. When I try to load a spec from the same internal HTTP server, Swagger UI displays, "No operations defined in spec!" and the validator icon shows an error. The spec is in fact valid. It's just that on-line validator can't reach the spec on the internal server.

This is a regression from Swagger UI 2.2.x. Previously, it would render the spec's operations even when the spec failed to validate.

The work around is to put the spec in a location the validator can reach (for example a Gist). However, I still think this is a defect. We have to be able to load specs from internal servers.

[webron]

Yup, that looks like a bug. You should be able to set as a configuration validatorUrl: null and that should disable it. Regardless, a broken validation should not break rendering of the spec.

[larshp]

also see https://github.com/swagger-api/swagger-ui/issues/2761

[bodnia]

@hlubovac @ddelay fix disable of validator is merged to latest master. When passing validatorUrl other than undefined then validator badge is not shown. In fact this is not related to operations render, as they are separate components.

As per fetching spec url, I tested 3 cases: when index.html is opened as a file in browser, served with our dev server (npm run dev) and build-in simple Webstorm server and passing spec url as config into SwaggerUIBundle and with query parameter both worked. Testing spec was hosted on simple https://www.npmjs.com/package/gulp-connect server with CORS enabled. I wonder if @hlubovac @ddelay you can send me the spec to investigate what may go wrong.

[hlubovac]

I'll send you mine, if you publish your email address (I'd rather not share publicly). Or, ask your 2 colleagues, @fehguy and @webron, to forward you the file that I sent them previously.

[ddelay]

@bodnia, the "No operations" problem appears to be fixed. My comment was about an earlier version of 3.0.x -- one that I was testing at the end of last week. Yesterday, I deployed the latest distribution from master and I am able to load specs from my internal server. Thanks.

[hlubovac]

@bodnia

Got the latest; some feedback on your change:

validatorUrl:null resulted in endpoint info displayed, but the red validator badge was still on the bottom of the page.

validatorUrl: undefined or that setting ommitted resulted in "No operations defined in spec!" message, with the red badge still showing.

So, basically, I don't see improvement. I'm pretty sure that I did update all relevant files ("dist"), and if it's some proof that I did taht, you changed preset configuration in index.html ("SwaggerUIStandalonePreset").

Maybe look for conditions related to showing "No operations defined in spec!" message. I was curious and searched, and I see it's mentioned in "src/core/components/operations.jsx" and "src/core/components/overview.jsx", but I don't understand that ES6 syntax. Maybe there's something wrong within specSelectors.taggedOperations() function that results in empty result mistakenly returned?

Or perhaps some timing issue related to premature processing of yet incompletely downloaded specs file (since the problem appears intermittent)?

Sorry, I can't step through any of the client code because, each time I open F12 tools this always results in same error message". It only intermittently won't work when I have F12 closed. I tried dozens of times.

[webron]

@hlubovac - I've forwarded your spec to @bodnia.

[bodnia]

@hlubovac which browser do you use? And can you please check if the spec fully comes from server (in devtools Network tab)?

[hlubovac]

I use Chrome mostly. The spec file is present, whether downloaded or loaded from browser's cache. Amazingly, this time the UI got rendered, even though browser's console was open. Speaking of the "network tab", online.swagger.io/validator call is being made regardless of my setting validatorUrl:null, and I was able to see how the rendering is delayed exactly until that call returned. Is there supposed to be a way to switch this off or not yet?

[bodnia]

@hlubovac on which commit are you now?

[hlubovac]

I noticed that, with validator:null, the validator IMG isn't getting inserted into the document when the page is served by localhost, while for other hosts that IMG gets rendered no matter what. I bet you have some logic like if (host != "localhost" && !validatorUrl) validatorUrl = "https://online.swagger.io/...";

[hlubovac]

Tuesday, but I'll download latest now: I see that there's been some changes.

[bodnia]

We check if validatorUrl !== undefined

[hlubovac]

I did try omitting that setting and even setting it explicitly to undefined. But, I'll try again.

[hlubovac]

Got the latest. Made sure that I do not have previous versions cached (post deployment and after each config change). Concluded the following:

This is also my observation: when online.swagger.io/validator is invoked, UI is completely blocking. So, it's somehow synchronous: it looks like your code is somehow waiting for that call to come back - because, only after it comes back I see the endpoint UI or error message, depending on the mood of the internal boogeyman. I'm also pretty sure that rendering of the UI (when it's about to be "successful") is also blocking: e.g. the code waits until the whole html is built-up and then is displays it, as opposed to maybe appending UI elements are they are discovered (but that is another topic, and perhaps you're working on improving this still). Anyway, depending on the length of time these two processes take, complete browser (beyond the relevant tab; Chrome, at least) is unresponsive (it won't even close immediately) - but I blame Chrome for this (it's supposed to keep tab content in isolation, and it's obviously not doing a good job there).

Tried Firefox briefly also, but the results are, more or less, the same.

I hope that helps.

[bodnia]

@hlubovac load badge image async is merged to master

[mgeorgy]

@bodnia I can confirm that this now works as expected.

adding:
validatorUrl: null,

to index.html prevents the validation error. I found no indications in the network panel that the js attempted to contact the validator service.

[hlubovac]

@bodnia, I misled you with those F12-related diagnostics - I apologize.

Could you point me to the code file where request for swagger-json is made, please? I want to confirm a theory before I report another potential problem. Thanks.

validatorUrl:null works for me. Thank you.

[bodnia]

@hlubovac here is fetch of swagger spec https://github.com/swagger-api/swagger-ui/blob/master/src/core/plugins/download-url.js#L14-L20

[hlubovac]

@bodnia

I can't see what I was looking for there - but, I'll describe what I noticed. Please advise if I should create another issue or if this isn't anything that is caused by your code.

My setup of swagger-ui is a little bit special: it's behind custom login, which sets up auth cookie, which is expected with requests for every one of the locally-hosted swagger-ui files, including the swagger-json.

That custom cookie is being sent up along with any request for static files (e.g. "swagger-ui.bundle.js", "swagger-ui.css"), but not swagger-json request. I cannot determine if this is due to how the request is being made or something that I cannot see on my end. Because of this, I get a 302 to the login page, and because I didn't notice this at the time, I wrongly concluded that the failing parsing was due to F12-tools being open (because I coincidentally had "disable cache" enabled there, which gets applied only when the debugging tools are enabled). I feel a little bit ashamed, but I'll be a man and admit that. I'm sorry about that. There's a bunch of unrelated things that I'm tackling on a daily basis, and it's easy to get distracted.

I'm pretty sure that I'm setting up the cookie correctly: it works as intended with swagger-ui v2, and 5 other swagger-ui flavors. It's restricted to the same domain and path where all files, including swagger-json, are located. As a matter of fact, being logged-in, when I just paste that URL to another browser's tab, I get content.

[webron]

@hlubovac so, to better manage tickets, I'm going to close this one out. There's a way to disable the validator which was the main issue.

As for the cookie issue - please open a separate one, but also check the existing ones because some do talk about cookie support and we've made a few changes there (so make sure to test master). If the issue persists, try to provide us with as many details as possible, because obviously, we don't have that set up.