kratos
kratos copied to clipboard
ory
Settings flow should not return UI nodes for metadata fields
Preflight checklist
- [X] I could not find a solution in the existing issues, docs, nor discussions.
- [X] I agree to follow this project's Code of Conduct.
- [X] I have read and am following this repository's Contribution Guidelines.
- [ ] This issue affects my Ory Cloud project.
- [X] I have joined the Ory Community Slack.
- [X] I am signed up to the Ory Security Patch Newsletter.
Describe the bug
I added a field to the public metadata:
{
"properties": {
"metadata_public": {
"type": "object",
"properties": {
"picture": {
"type": "string",
"format": "uri"
}
},
"additionalProperties": false
},
"traits": {}
}
Since the metadata shouldn't be editable by the user, I would expect that the UI container for the settings flow does not contain any input nodes for the picture field. However, Kratos is returning an input for the metadata field:
{
"attributes": {
"name": "metadata_public.picture",
"node_type": "input",
"type": "url"
},
"group": "profile",
"messages": [],
"meta": {},
"type": "input"
}
Reproducing the bug
- add a metadata field to an identity schema
- initiate a settings flow or registration flow
Relevant log output
No response
Relevant configuration
No response
Version
0.10.1
On which operating system are you observing this issue?
No response
In which environment are you deploying?
Docker Compose
Additional Context
No response
The field public_metadata is not validated against the JSON Schema. Adding it to the schema has no effect :)
Not sure, the metadata fields are set arbitrary and have no implication on Ory Kratos' business logic. The JSON Schema for traits is used when validating UI input, generating UI nodes, etc.
The only reason could be enforcement of a schema, but at the cost of added learning complexity when starting out with Ory Kratos.
Kratos is the last thing before the database. I think it would be reasonable to enforce the schema before persisting the data at that point. Apart from validation, it would also be nice to have the metadata format as part of the schema, so that anybody who handles identities knows what to expect.
I don't follow your argument about added learning complexity. You need to know how to define a JSON schema right from the start, so that you can set up your identity traits. The metadata then works just the same as the traits (minus ory.sh/kratos extensions). Also, the metadata is probably not the first thing you need when integrating a service.