when adding a custom field to traits : properties ...
# talk-kratos
i
when adding a custom field to traits : properties : myfield , how do i actually create an identity with the field? POST on /admin/identities is rejected with ""reason":"I[#/traits] S[#/properties/traits/additionalProperties] additionalProperties \"tenants\" not allowed"
b
i
probably in the wrong place. metadata sounds correct, since this isnt supposed to be user facing, but its not documented how to set it
this is my schema:
Copy code
{
  "$id": "<https://schemas.ory.sh/presets/kratos/identity.email.schema.json>",
  "title": "Person",
  "type": "object",
  "properties": {
    "traits": {
      "type": "object",
      "properties": {
        "email": {
          "type": "string",
          "format": "email",
          "title": "E-Mail",
          "<http://ory.sh/kratos|ory.sh/kratos>": {
            "credentials": {
              "password": {
                "identifier": true
              },
              "webauthn": {
                "identifier": true
              },
              "totp": {
                "account_name": true
              }
            },
            "recovery": {
              "via": "email"
            },
            "verification": {
              "via": "email"
            }
          },
          "maxLength": 320
        },
        "tenants": {
          "type": "array",
          "title": "Tenant IDs",
          "items": {
            "type": "string"
          }
        }
      },
      "required": [
        "email"
      ],
      "additionalProperties": false
    }
  }
}
b
In general, traits are meant to be changed by the user. You can work around this by manually hiding the field in your custom UI, but our hosted UI does not (currently) allow this. The schema however looks correct, at first glance. How do you create the identity?
i
thats sounds dangerous. i want to use this for multi tenancy. i.e. the field absolutely must not be user editable
Copy code
curl --request POST -sL \
--header "Authorization: Bearer ory_pat_SCredacted" \
--data '{
  "schema_id": "<preset://email>",
  "traits": {
    "email": "<mailto:docs@example.org|docs@example.org>", "tenants": ["bob"]
  }
}' <https://boring-raman-1u4afyrrtk.projects.oryapis.com/admin/identities>
b
Yeah, the UI is probably not the place to that… The issue is the
schema_id
parameter. If you leave it out and set your schema to be the default, it works.
i
oooh thanks
i guess there's no way to set the field to not be user editable? the docs arent very clear on that
b
Yeah, I just noticed as well. We are working on that, though. You could try and see if
metadata_admin
works for you here. We do not support multi tenancy in this way though. One way how it works is by using multiple Ory Cloud projects.
i
we have thousands of tenants, that's not going to work
metadata_admin isnt returned in whoami, but metadata_public should be safe?
b
Yes, metadata_admin is only accessible via the admin API. Right, metadata_public should work, but keep in mind that user’s can see that data. (They just can’t modify it.)
i
that's perfect.
_public is a weird name then
also the warning is very confusing, "dont put anything in there without the users cosent" sounds like its visible to someone not the user
b
Which warning do you mean? It still requires a session to get the data. So in that sense it’s safe.
i
somewhere in the docs, sorry i forgot
this works, thanks 🙂
b
Ah, I see. As I said we are actively working on the docs, and definitely need to clarify these things.