-
Notifications
You must be signed in to change notification settings - Fork 9k
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
Comments
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. |
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. |
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. |
Yup, that looks like a bug. You should be able to set as a configuration |
also see #2761 |
#2796 disable validator (with badge) by removing it from config
@hlubovac @ddelay fix disable of validator is merged to latest As per fetching spec url, I tested 3 cases: when index.html is opened as a file in browser, served with our dev server ( |
@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 |
Got the latest; some feedback on your change:
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 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. |
@hlubovac which browser do you use? And can you please check if the spec fully comes from server (in devtools Network tab)? |
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 |
@hlubovac on which commit are you now? |
I noticed that, with |
Tuesday, but I'll download latest now: I see that there's been some changes. |
We check if |
I did try omitting that setting and even setting it explicitly to |
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. |
@hlubovac load badge image async is merged to |
@bodnia I can confirm that this now works as expected. adding: to index.html prevents the validation error. I found no indications in the network panel that the js attempted to contact the validator service. |
@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.
|
@hlubovac here is fetch of swagger spec https://github.com/swagger-api/swagger-ui/blob/master/src/core/plugins/download-url.js#L14-L20 |
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. |
@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. |
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://
andfile:///
.Thanks.
The text was updated successfully, but these errors were encountered: