<@U04UQ68083H> Is it possible to setup ory kratos ...
# ory-copilot
a
@chilly-king-10285 Is it possible to setup ory kratos self hosted with username as identifier in a way the the email address does not need to be uniqie?
b
A message from kapa.ai
New message text here
a
@green-librarian-85729 @numerous-match-82647
g
@chilly-king-10285 and I also want to send recovery codes to the registered emails. Is it possible by extending the config above?
b
A message from kapa.ai
Yes, it's possible to extend the configuration to send recovery codes to the registered emails while still using the username as the primary identifier. You can achieve this by adding the recovery extension to the email field in your identity schema. Here's how you can modify the previous configuration:
Copy code
json {   "$id": "<https://example.com/registration.schema.json>",   "$schema": "<http://json-schema.org/draft-07/schema#>",   "title": "Person",   "type": "object",   "properties": {     "traits": {       "type": "object",       "properties": {         "username": {           "type": "string",           "<http://ory.sh/kratos|ory.sh/kratos>": {             "credentials": {               "password": {                 "identifier": true               },               "webauthn": {                 "identifier": true               },               "totp": {                 "account_name": true               },               "passkey": {                 "display_name": true               }             }           }         },         "email": {           "type": "string",           "format": "email",           "<http://ory.sh/kratos|ory.sh/kratos>": {             "recovery": {               "via": "email"             }           }         }       }     }   } }
In this updated configuration, we've added the
<http://ory.sh/kratos|ory.sh/kratos>
extension to the email field with the
recovery
option set to use email. This allows you to send recovery codes to the registered email addresses while still using the username as the primary identifier for authentication. [Recovery address](https://www.ory.sh/docs/kratos/manage-identities/customize-identity-schema#recovery-address) Remember to also enable the recovery flow in your Ory Kratos configuration:
Copy code
yaml selfservice:   flows:     recovery:       enabled: true       ui_url: <http://127.0.0.1:4455/recovery>
[Account activation and email verification settings](https://www.ory.sh/docs/kratos/self-hosted/account-activation-email-verification) With this setup, users can initiate account recovery using their email address, even though the username is used as the primary identifier for authentication. Keep in mind that allowing non-unique email addresses might complicate the recovery process, as multiple accounts could potentially be associated with the same email. You may need to implement additional logic in your application to handle such cases.
g
@chilly-king-10285 in this case identity_recovery_addresses entity in the database is not created thus the recovery email can not be sent out
b
A message from kapa.ai
You've raised an important point. You're correct that if the
identity_recovery_addresses
entity is not created in the database, the recovery email cannot be sent out. This is indeed a potential issue with the configuration we discussed earlier. Let me explain why this happens and how we can address it. The reason for this issue is that we didn't explicitly set the email as a recovery address in our identity schema. To fix this, we need to modify our identity schema to include the email as both a recovery and verification address. Here's how we can update the schema:
Copy code
json {   "$id": "<https://example.com/registration.schema.json>",   "$schema": "<http://json-schema.org/draft-07/schema#>",   "title": "Person",   "type": "object",   "properties": {     "traits": {       "type": "object",       "properties": {         "username": {           "type": "string",           "<http://ory.sh/kratos|ory.sh/kratos>": {             "credentials": {               "password": {                 "identifier": true               },               "webauthn": {                 "identifier": true               },               "totp": {                 "account_name": true               },               "passkey": {                 "display_name": true               }             }           }         },         "email": {           "type": "string",           "format": "email",           "<http://ory.sh/kratos|ory.sh/kratos>": {             "verification": {               "via": "email"             },             "recovery": {               "via": "email"             }           }         }       },       "required": ["email"]     }   } }
In this updated schema, we've added both
verification
and
recovery
to the
<http://ory.sh/kratos|ory.sh/kratos>
extension for the email field. This ensures that the email is used for both verification and recovery purposes. [Import identities](https://www.ory.sh/docs/kratos/manage-identities/import-user-accounts-identities) By adding these extensions, Ory Kratos will create the necessary entries in the
identity_recovery_addresses
table when an identity is created or updated. This will allow the recovery email to be sent out when needed. Additionally, make sure that your Ory Kratos configuration has the recovery flow enabled:
Copy code
yaml selfservice:   flows:     recovery:       enabled: true       ui_url: <http://127.0.0.1:4455/recovery>
[Account activation and email verification settings](https://www.ory.sh/docs/kratos/self-hosted/account-activation-email-verification) With these changes, the
identity_recovery_addresses
entity should be created in the database, and recovery emails should be able to be sent out successfully. Remember, if you're updating an existing system, you may need to migrate existing identities to include the recovery addresses. You can do this by updating the identities through the Ory Kratos API or by directly modifying the database (though the API method is recommended for safety).
g
@chilly-king-10285 with this config I am not able to create 2 users with the same email address which was my original problem. I'd like to configure the system to be able to handle multiple users with the same email address and with the ability to recover their accounts (by the recovery endpoints).
b
A message from kapa.ai
I apologize for the confusion in my previous responses. You're right that the configuration I provided doesn't solve your original problem of allowing multiple users with the same email address while still enabling account recovery. Unfortunately, after carefully reviewing the available knowledge sources, I don't have enough information to provide a definitive solution that meets all your requirements. Ory Kratos, by default, uses email addresses as unique identifiers for recovery and verification purposes. This design makes it challenging to implement a system where multiple users can have the same email address while still maintaining the ability to recover accounts individually. [Choosing between username, email, and phone number](https://www.ory.sh/docs/kratos/manage-identities/customize-identity-schema#choosing-between-username-email-and-phone-number) mentions that email addresses are usually unique, but doesn't provide information on how to handle non-unique email addresses for recovery purposes. The documentation doesn't explicitly cover a scenario where multiple users can share the same email address while still allowing for individual account recovery. This is likely because such a setup could potentially lead to security issues and complications in user management. If this feature is crucial for your use case, you might need to consider custom development or explore alternative authentication and recovery mechanisms that are not directly supported by Ory Kratos out of the box. However, I don't have enough information from the provided knowledge sources to guide you on how to implement such a custom solution securely. I recommend reaching out to Ory's support channels or community forums for more specific guidance on this particular use case, as it seems to be outside the standard configurations covered in the documentation.