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

Email field type changes on second request for request context during registration flow #670

Closed
jousby opened this issue Aug 25, 2020 · 2 comments · Fixed by #698
Closed
Labels
bug Something is not working. corp/m2 Up for M2 at Ory Corp. good first issue A good issue to tackle when being a novice to the project. help wanted We are looking for help on this one.

Comments

@jousby
Copy link

jousby commented Aug 25, 2020

Describe the bug

The field type appears to change for the 'traits.email' field after the initial attempt to register an account is unsuccessful. The field starts of with a type of 'email' and then changes to having a type of 'text'. In my application I'm using the type value to make decisions about how to render input fields. The 'kratos-selfservice-ui-node' application appears to be not affected by this as it switches on the field name for making rendering decisions.

Reproducing the bug

Using the same default schema as the kratos-selfservice-ui-node, the first time you start the registration flow and make a call to fetch the request context the form field descriptions for the password method come back as follows (note the type for 'traits.email' is 'email'):

0: {name: "csrf_token", type: "hidden", required: true, value: "<redacted>"}
1: {name: "password", type: "password", required: true}
2: {name: "traits.email", type: "email"}

If the user submits a request and is unsuccessful (due to using a common password as an example) and is redirected back to the registration form, the second request to fetch the request context then looks like the following (note the type for 'traits.email' is now 'text'):

0: {name: "csrf_token", type: "hidden", required: true, value: "<redacted>"}
1: {name: "password", type: "password", required: true, messages: Array(1)}
2: {name: "traits.email", type: "text", value: "q@q.com"}

Expected behavior

I think it is reasonable to expect the 'type' of a field to remain consistent across calls to retrieve a request context with the same request id.

Environment

  • Version: 0.4.6.alpha
  • Environment: Docker Desktop on macOS Mojave

Additional context

N/A

@aeneasr aeneasr added the bug Something is not working. label Aug 25, 2020
@aeneasr aeneasr added this to the v0.5.0-alpha.1 milestone Aug 25, 2020
@aeneasr aeneasr added corp/m2 Up for M2 at Ory Corp. good first issue A good issue to tackle when being a novice to the project. help wanted We are looking for help on this one. labels Aug 25, 2020
@aeneasr
Copy link
Member

aeneasr commented Aug 25, 2020

Definitely a bug! PRs appreciated

@jousby
Copy link
Author

jousby commented Aug 25, 2020

I do like the Ory projects enough that i'm considering investing some time in learning Go. I'm not going to be able to help here in the short term though. This one's open for any other contributors looking for a nice issue to get started on.

zepatrik added a commit that referenced this issue Sep 21, 2020
aeneasr added a commit that referenced this issue Sep 24, 2020
closes #670

Co-authored-by: hackerman <3372410+aeneasr@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is not working. corp/m2 Up for M2 at Ory Corp. good first issue A good issue to tackle when being a novice to the project. help wanted We are looking for help on this one.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants