Skip to content
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

UserAuthCard doesn't format the form body traits correctly #93

Open
6 tasks done
JacobMillward opened this issue Feb 16, 2023 · 4 comments · May be fixed by #104
Open
6 tasks done

UserAuthCard doesn't format the form body traits correctly #93

JacobMillward opened this issue Feb 16, 2023 · 4 comments · May be fixed by #104
Labels
bug Something isn't working

Comments

@JacobMillward
Copy link

Preflight checklist

Describe the bug

When submitting the a registration form using UserAuthCard, the body object returned to the callback on the onSubmit prop formats the object incorrectly.
What is expected is:

{
    traits: {
        email: '[email protected]'
    },
    //... other
}

What is given is:

{
    "traits.email": '[email protected]',
    //... other
}

This means that unless care is taken, form values are not passed up to kratos correctly.

Reproducing the bug

  • Use Ory Elements to create a login form connected to Ory Kratos.
  • Observe the object give back in the onSubmit callback

Relevant log output

No response

Relevant configuration

No response

Version

0.0.1-beta.3

On which operating system are you observing this issue?

Other

In which environment are you deploying?

Kubernetes with Helm

Additional Context

No response

@JacobMillward JacobMillward added the bug Something isn't working label Feb 16, 2023
@Benehiko
Copy link
Contributor

Hey @JacobMillward

Have you gotten errors form Ory Kratos when submitting the registration payload provided by Ory Elements? I believe Ory Kratos flat maps the object when giving the ui form fields.

For example:

{
  traits: {
    email: string
  }
}

will become <input type="email" name="traits.email" /> inside the UI since Kratos' flow payload returns the UI node names flat mapped as shown here https://github.com/ory/elements/blob/main/src/stories/Ory/register-flow.json#L70-L78.

@JacobMillward
Copy link
Author

JacobMillward commented Feb 20, 2023

Have you gotten errors form Ory Kratos when submitting the registration payload provided by Ory Elements?

Yup I did. Kratos kept giving back the error that the email could not be empty.
My workaround was to unflatten it e.g.

await kratos.updateRegistrationFlow({
    flow: String(flow?.id),
    updateRegistrationFlowBody: {
        ...formBody,
        traits: {
            email: (formBody as any)["traits.email"],
        },
    },
});

@Benehiko
Copy link
Contributor

Hmm interesting 🤔
Could you share your identity schema?

@JacobMillward
Copy link
Author

Sure. It's the example from the kratos helm configuration page

{
  "$id": "https://schemas.ory.sh/presets/kratos/identity.email.schema.json",
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Person",
  "type": "object",
  "properties":
    {
      "traits":
        {
          "type": "object",
          "properties":
            {
              "email":
                {
                  "type": "string",
                  "format": "email",
                  "title": "Email",
                  "ory.sh/kratos":
                    {
                      "credentials": { "password": { "identifier": true } },
                      "recovery": { "via": "email" },
                      "verification": { "via": "email" },
                    },
                },
            },
          "required": ["email"],
          "additionalProperties": false,
        },
    },
}

DASPRiD added a commit to DASPRiD/ory-elements that referenced this issue Mar 20, 2023
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
@DASPRiD DASPRiD linked a pull request Mar 20, 2023 that will close this issue
6 tasks
DASPRiD added a commit to DASPRiD/ory-elements that referenced this issue Mar 20, 2023
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
DASPRiD added a commit to DASPRiD/ory-elements that referenced this issue Mar 20, 2023
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
Benehiko pushed a commit to DASPRiD/ory-elements that referenced this issue Jun 26, 2023
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
Benehiko pushed a commit to DASPRiD/ory-elements that referenced this issue Jun 26, 2023
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants