Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Way to disable validator? #2796

Closed
hlubovac opened this issue Mar 27, 2017 · 24 comments
Closed

Way to disable validator? #2796

hlubovac opened this issue Mar 27, 2017 · 24 comments
Assignees

Comments

@hlubovac
Copy link

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.

image

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
Copy link
Author

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
Copy link
Author

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
Copy link

ddelay commented Mar 27, 2017

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
Copy link
Contributor

webron commented Mar 27, 2017

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
Copy link

larshp commented Mar 28, 2017

also see #2761

bodnia added a commit to bodnia/swagger-ui that referenced this issue Mar 29, 2017
bodnia added a commit that referenced this issue Mar 29, 2017
#2796 disable validator (with badge) by removing it from config
@bodnia
Copy link
Contributor

bodnia commented Mar 29, 2017

@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
Copy link
Author

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
Copy link

ddelay commented Mar 29, 2017

@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
Copy link
Author

hlubovac commented Mar 29, 2017

@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
Copy link
Contributor

webron commented Mar 29, 2017

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

@bodnia
Copy link
Contributor

bodnia commented Mar 30, 2017

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

@hlubovac
Copy link
Author

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
Copy link
Contributor

bodnia commented Mar 30, 2017

@hlubovac on which commit are you now?

@hlubovac
Copy link
Author

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
Copy link
Author

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

@bodnia
Copy link
Contributor

bodnia commented Mar 30, 2017

We check if validatorUrl !== undefined

@hlubovac
Copy link
Author

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

@hlubovac
Copy link
Author

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

image

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
Copy link
Contributor

bodnia commented Mar 31, 2017

@hlubovac load badge image async is merged to master

@mgeorgy
Copy link

mgeorgy commented Mar 31, 2017

@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
Copy link
Author

@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
Copy link
Contributor

bodnia commented Mar 31, 2017

@hlubovac
Copy link
Author

hlubovac commented Mar 31, 2017

@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
Copy link
Contributor

webron commented Mar 31, 2017

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants