-
Notifications
You must be signed in to change notification settings - Fork 91
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
using App.create(<url>) with HTTPS, auth, and custom headers? #107
Comments
In short:
The issue described a way to make custom request against an API service, which is not for the case to load the OpenAPI definitions and discover what functionality that service provide. Usually speaking, the should not be a need to provide auth info when requesting the OpenAPI definitions. It's not very hard to write one client to fulfill what you need by referencing pyswagger.contrib.client.requests. By the way, can I know the use case to manipulate the session used to load OpenAPI JSON definition? |
I was hoping to leverage the Swagger 1.2 definitions within another vendor's product, and to access their definitions, they require you to 1st make a POST call to an API to get a token, then all subsequent calls must have the X-Auth-Token header set with that value. Their api-docs are protected and require the auth token to be set to access them. Also, in some cases customer installations of this product may use self-signed certificates which may fail SSL cert validation, so the ability to skip verification, or point to custom certs for validation is required also. My 1st approach was to create a custom Getter, and then use App.load(getter=CustomGetter) and App.prepare() manually instead, but this failed during the App.prepare() step and the logging wasn't intuitive as to why. Here is a quick example of the custom Getter I used (this test was done in Python 3.6.0):
And here is the result from that approach so far:
The App appears to follow and pull the 2 corresponding JSON definitions as you can see from the two |
So I'll leave one more comment before you respond 😉 I believe there may be errors in the vendor's Swagger 1.2 definitions after evaluating it's content in another tool. I see now where they have the "type" of several parameters and refs set to non-existent models I would still be curious to know if the above approach with the custom getter should work though, if I fix their models... |
Things you did so far is just correct, I've loaded the json content in your comment and logging the errors:
In short, the provide name "fileUpload" for body parameters, which is meaningless and prohibited by OpenAPI 1.2 spec (ref). But it should be just fine to use this spec by skipping the validation step of pyswagger, by this: # instead of calling App.prepare
App.prepare(strict=False) Once you skip the validation, you'll fail with this error, which means pyswagger failed to resolve some '$ref'
This $ref is from definitions.FileObject.properties.attributeInfo, things you can try:
My action items:
|
- make writing a custom getter for url easier - #107
those actions items (and test cases) are included in the latest build: v0.8.27, please feel free to reopen it if it's not what you expected. |
- make writing a custom getter for url easier - pyopenapi/pyswagger#107
[fix] - using App.create(<url>) with HTTPS, auth, and custom headers? pyopenapi/pyswagger#107 - multiple protocol https: appended request.url in client.request pyopenapi/pyswagger#109 [new] - add pyswagger.getter.SimpleGetter - pyswagger.io.Request and pyswagger.io.Response has reset(), and could be reused.
For what it's worth, I disagree with this statement. I can think of many swagger APIs I use that are part of private systems, that absolutely require authentication to access the API schema. It's kind of ridiculous that I have to write a custom getter for this. Why not just use requests everywhere? |
@wryfi Indeed, I agree with you now, it's the usual case that auth is required when making requests. But I still didn't see a way to embed this part (especially OAuth2) in this library that could provide cleaner code than using |
@wryfi I just go through the document of |
I see in #60 that there was an addition to allow a Client to pass additional parameters to requests, but at 1st glance, it looks like the App.create() method uses a urllib getter that doesn't allow any manipulation of the session used to get access the URL that contains the OpenAPI JSON definition. Is that correct, or did I miss an intended pattern to allow dealing with cert issues, auth methods, and potentially required headers when pulling the JSON definitions via remote URL?
Thanks!
The text was updated successfully, but these errors were encountered: