-
-
Notifications
You must be signed in to change notification settings - Fork 46
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
fix: unflatten form data into correct body format #104
base: main
Are you sure you want to change the base?
Conversation
ab0745e
to
e27f290
Compare
Still not sure why we need to unflatten data when the data is unflattened in Kratos. Please take a look at some of the examples. These examples all work perfectly fine against Ory and are tested. https://github.com/ory/elements/blob/main/examples/nextjs-spa/src/pages/login.tsx#L88-L102 Are you getting errors when trying Ory Elements against Ory Kratos? Could you please give me more information on what exactly isn't working. |
It is working fine at the moment, because the currently generated SDK does not verify the input parameters. When a newer generator is used (which is planned, see ory/sdk#256 (comment)), the input parameters are actually checked. Alternatively, the API schema could be updated for these endpoint to allow |
I see, thank you for the link and clarification. Could you rebase your branch so we can have e2e tests run on this branch? I will then review and see to merge this :) |
Sure, I'll take care of that later tonight. Though what's your opinion on that manual unflattening? It does feel a little bit hacky, we could alternatively use the npm library It could look something like this then: const body = unflatten<unknown, UpdateBody>(
Object.fromEntries(formData)
); |
I will need to look into the implementation a bit, but yes I agree that using a library might be better if the library is well tested and maintained. |
@Benehiko please revisit |
9ff7260
to
7e6d179
Compare
The format for bodies with traits dictates that the traits come in through their own object. This becomes especially visible when using an SDK client compiled with a newer version of OpenAPI generator, as they only process properties which are defined in the API schema, which is not the case for flattened properties. Fixes ory#93
I was having the same issue but when looking at the request being sent by the browser (when posting the registration form) I discovered that it never send out the Thus the request was: {
"csrf_token" : "...",
"method": "password",
"password": "..."
} instead of {
"csrf_token" : "...",
"method": "password",
"password": "...",
"traits.email": "..."
} The reason As a workaround I'm going to implement an unflatten of the keys to make it fit the TypeScript definitions (as the linked PR is doing) but it's understandable that the maintainers might never accept that PR. The best option is probably to fix the openapi spec that generates the |
The format for bodies with traits dictates that the traits come in through their own object. This becomes especially visible when using an SDK client compiled with a newer version of OpenAPI generator, as they only process properties which are defined in the API schema, which is not the case for flattened properties.
Fixes #93
Checklist
If this pull request addresses a security vulnerability,
I confirm that I got green light (please contact [email protected]) from the maintainers to push the changes.