-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
[Python] Support for HTTP signature #4958
[Python] Support for HTTP signature #4958
Conversation
@sebastien-rosset can you provide some extra context around this PR? |
This looks really neat. I have a couple of points.
|
Do you mean codegen versus language specific (Python) changes?
I have opened #4992 for the openapiv3 Python experimental samples
makes sense, will do. |
@taxpon @frol @mbohlool @cbornet @kenjones-cisco @tomplus @Jyhess @slash-arun @spacether |
Yes, the codegen vs the language specific implementation. Thanks for opening that PR 👍 |
modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java
Outdated
Show resolved
Hide resolved
modules/openapi-generator/src/main/resources/python/python-experimental/setup.mustache
Show resolved
Hide resolved
@sebastien-rosset can you resolve the merge conflict? |
sure, working on it. Update 2: The build has passed. |
I looked at what would happen if there were unusual characters in the "path" or "query" segments of the URL, and how that would impact HTTP signature. There are some subtleties, so I opened OAI/OpenAPI-Specification#2119 and #5117. I think I may have to submit another PR to handle that situation, after we agree on what is the expected character encoding in the OAS spec. |
Thank you! |
This is adding a new "HTTP signature" security schemes (https://datatracker.ietf.org/doc/draft-cavage-http-signatures/)? HTTP signatures is still a IETF draft, and hopefully it will become an official RFC this year. On one hand one may argue it shouldn’t be added because it’s still a draft, but on the other hand it is already being used by multiple products, so there may be benefits to support it. It is possible multiple organizations are independently adding the same security scheme.
Ideally one way to address the problem would be to make it possible to add new security schemes (such as HTTP signature) without being required to fork the OpenAPITools repo. But given the current code structure, it’s not clear to me how this could be achieved. Adding new security schemes involves surgery in multiple locations (Java codegen, templates, mustache tags).
I raised this point in Slack before opening the PR.
This PR depends on #4993 and #4992.
PR checklist
./bin/
(or Windows batch scripts under.\bin\windows
) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run./bin/{LANG}-petstore.sh
,./bin/openapi3/{LANG}-petstore.sh
if updating the code or mustache templates for a language ({LANG}
) (e.g. php, ruby, python, etc).master
,4.3.x
,5.0.x
. Default:master
.