Add --no-verify-ssl argument
Is your feature request related to a problem? Please describe.
Sometimes self-signed certificates are used during local development (for example when hosting over https://localhost). Currently openapi-python-client (rightly) fails to connect to self-signed HTTPS endpoints:
openapi-python-client generate --url https://localhost/openapi --fail-on-warning --meta setup
Error(s) encountered while generating, client was not created
Could not get OpenAPI document from provided URL
Describe the solution you'd like
Add a new --no-verify-ssl command line option that would allow developers to opt in to disabling SSL verification. This should of course not be the default.
Describe alternatives you've considered
openapi-generator supports this through the use of (hard to use/understand) Java environment variables:
export JAVA_TOOL_OPTIONS="-Dio.swagger.parser.util.RemoteUrl.trustAll=true -Dio.swagger.v3.parser.util.RemoteUrl.trustAll=true"
Ideally, a simple command line option would be much more discoverable and easy to use.
I believe the no-verify bool would need to be passed to:
https://github.com/openapi-generators/openapi-python-client/blob/aa4f6b59e9d32b34e27191f20e8b5c2f110ee250/openapi_python_client/init.py#L386
httpx docs: https://www.python-httpx.org/advanced/#changing-the-verification-defaults
import httpx
r = httpx.get("https://example.org", verify=False)
If you have the certificates installed on the system and you can connect with curl without the -k option, you can set the SSL_CERT_DIR or SSL_CERT_FILE environment variables. On ubuntu, it would be this.
export SSL_CERT_DIR=/etc/ssl/certs
openapi-python-client generate --url=https://yourhost/openapi.json
while it may not be quite what you want since its at
library use time instead of generation time
we do have a verify_ssl attr for Client
the user can set it to False or initialize it as False in the constructor
client.verify_ssl = False
If forcing the library user to do that is too much you could also set it to false
by default by modifying the client.py.jinja template in --custom-template-path folder
You could also download the OpenAPI file locally first and then pass it as a --path to openapi-python-client instead of --url. I don't really want to get in the business of tweaking ways to fetch remote documents beyond the simple, no-config get request. I could maybe be convinced to add support for reading the spec from stdin so you could pipe from curl or something to be a bit more unixy then saving to a file.
Bash will also let you pipe a command as a file.
openapi-python-client --path <(curl https://example.com/openapi.json)
I think we're not going to add --no-verify-ssl, the workarounds provided by folks above seem good enough.