-
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
$ref downloading doesn't use requestInterceptor #3763
Comments
I overlooked this detail 😬 the initial fetch is handled in Swagger-UI, but Swagger-Client handles $ref resolution. Relevant code is here: https://github.com/swagger-api/swagger-js/blob/master/src/resolver.js#L5 |
@shockey: Thanks for the very fast fixing of #2793 ! Is it foreseeable when the Swagger-Client will support handling the $ref URLs from a protected server? |
@CarstenRilke, I can't give an estimate on this - it depends on how much work is involved in handing off the UI's interceptors to the Swagger-Client resolver. I'll be taking a look at it within the next couple of days, but no estimate on a fix. Stay tuned! |
Good news - this is fixed! The patch will be released tomorrow evening as part of our weekly release. Thanks for the report, @scottohara! |
You do an amazing job, @shockey. Many thanks. |
Thanks for the fast fix! |
Have been testing v3.4.0 today...unfortunately I've not yet been able to confirm that this change was successful. The The ...but the In the Chrome DevTools debugger, setting a breakpoint in my |
@scottohara, I believe you're right. It appears that Swagger-UI is only providing its interceptors at request time, which doesn't give Swagger-Client the chance to use them in the newly-aware-of-interceptors resolver. My apologies here, I didn't test the client changes against the UI before shipping. I'll look into this today, hopefully I can patch it up for this week's release. |
Okay, this should be working now - I tested it on my end before merging #3830. This will be released tomorrow evening as part of our weekly release. Thanks everyone! |
Demonstration API definition
The 'petstore' example from here:
https://github.com/OAI/OpenAPI-Specification/blob/master/examples/v2.0/json/petstore.json
The 'petstore-separate' example from here:
https://github.com/OAI/OpenAPI-Specification/tree/master/examples/v2.0/json/petstore-separate
...both hosted on a local server that requires basic authentication.
Configuration (browser query string, constructor, config.yaml)
Expected Behavior
In swagger-ui@3.3.2, #3738 fixes a gap where the
requestInterceptor()
wasn't being invoked for the download of the spec URL.Current Behavior
I have been testing this feature and can confirm that it works as expected for the initial spec URL.
For example, when loading the simple
petstore.json
example, therequestInterceptor
is invoked and the correctAuthorization: Basic <base64(admin:secret)>
header is passed in the fetch.Similarly, for the 'separate' example, the
requestInterceptor
is invoked on the fetch ofspec/swagger.json
and the correctAuthorization
header is passed.However, when resolving and fetching any the
$ref
URLs inspec/swagger.json
(i.e.spec/parameters.json
,spec/Pet.json
,spec/NewPet.json
andcommon/Error.json
), therequestInterceptor
doesn't appear to be invoked; and as a result these sub-fetches fail with a401 Unauthorized
.Possible Solution
Ensure that
requestInterceptor
is correctly called for any$ref
downloads.The text was updated successfully, but these errors were encountered: