-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
API generation bug regarding Accept Consent request session model #3058
Comments
Hm looks like a problem with the generator, the spec looks fine. Also if other languages are working properly, this suggests it's a bug in the generator. |
I've done some digging into how it's generated, it appears to have been a problem before |
We had this problem in Kratos, a good solution is to remove the To apply the patch, add it like so: https://github.com/ory/kratos/blob/e50551330d976845c696bf68b6d9b61221da59d3/Makefile#L93 |
Thanks @aeneasr I'll create a patch and submit a PR |
Apologies but I'd lik to reopen as the PR does not correct the definition: https://github.com/ory/hydra-client-go/blob/master/model_consent_request_session.go#L23 |
This PR didn't seem to fixed the the client repo? |
It's not yet released |
Preflight checklist
Describe the bug
The API generates an incorrect definition for the Accept Consent request session data model in the Go api client (ref ory/hydra-client-go#10)
Model in question:
https://github.com/ory/hydra-client-go/blob/master/model_consent_request_session.go#L23
It's type
"idToken": map[string]map[string]interface{}
when the API docs suggest it is"idToken": map[string]interface{}
The JS (node) api also sends an object of key: string, value: any. The dart api also has a similar mapping, but of String: JSONObject.
The model requires us to define the following body, which is not correct
Reproducing the bug
Relevant log output
Relevant configuration
n/a
Version
1.11.7
On which operating system are you observing this issue?
Linux
In which environment are you deploying?
Kubernetes
Additional Context
The openapi generator seems to incorrectly assume the value of the map and gives them a map instead
The text was updated successfully, but these errors were encountered: