The "after password" setting in the settings redirect configuration is used to specify where a user should be redirected after successfully updating their password in the settings flow. This is part of Ory's customizable redirection system for various authentication and user management flows. Specifically, in the settings flow configuration, you can set a redirect URL that will be used after a user changes their password. Here's an example of how it can be configured:

yaml selfservice:   flows:     settings:       after:         password:           # redirect after successfully updating the password in settings           default_browser_return_url: <https://end-up-here-after-login-with-password/>

In this configuration, after a user successfully updates their password in the settings flow, they will be redirected to the URL specified in the

default_browser_return_url

under the

password

section [Docs > Concepts > Browser redirects and flow completion > Redirect flows](https://www.ory.sh/docs/concepts/redirects#redirect-flows). It's important to note that this setting overrides any default redirect URL that might be set at a higher level in the configuration hierarchy. This allows for fine-grained control over user redirection based on specific actions within the settings flow.

Yes, it is possible to disable changing the email address on the settings page in Ory. This can be achieved by configuring the "privileged fields" in your Ory Identities (Kratos) setup. The email address is considered a protected or privileged field, and its modification can be controlled through the

privileged_session_max_age

setting. By setting this to a very short duration or to zero, you can effectively disable the ability to change the email address without re-authentication. Here's how you can configure this:

yaml selfservice:   flows:     settings:       # Set this to a very short duration or to zero       privileged_session_max_age: 0s

By setting

privileged_session_max_age

to zero, any attempt to change privileged fields (including the email address) will require immediate re-authentication, effectively disabling the ability to change these fields on the settings page without logging in again [Docs > Kratos > Self-service > Flows > Settings and profile updates > Updating privileged fields](https://www.ory.sh/docs/kratos/self-service/flows/user-settings#updating-privileged-fields). It's important to note that this approach doesn't completely remove the field from the settings page, but it makes it practically impossible to change without re-authentication. If you want to completely remove the ability to change the email address, you might need to customize your user interface to not display this option. Remember that disabling email address changes might impact user experience and account recovery options, so consider the implications carefully before implementing this restriction.

Yes, there is a way to make a field in the identity schema (such as the email) immutable after user creation in Ory Kratos. This can be achieved by using the

immutable

property in the JSON Schema for the identity. Here's an example of how you can make the email field immutable:

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": {         "email": {           "type": "string",           "format": "email",           "title": "E-Mail",           "<http://ory.sh/kratos|ory.sh/kratos>": {             "credentials": {               "password": {                 "identifier": true               }             },             "verification": {               "via": "email"             }           },           "maxLength": 320,           "immutable": true         }       },       "required": ["email"]     }   } }

In this example, we've added the

"immutable": true

property to the email field. This means that once the email is set during user creation, it cannot be changed in subsequent updates to the identity [Docs > Kratos > Manage-identities > Customize identity schemas > Examples > Email as the primary identifier](https://www.ory.sh/docs/kratos/manage-identities/customize-identity-schema#examples). By setting a field as immutable, you ensure that it remains constant throughout the lifecycle of the identity, even if attempts are made to modify it through the settings flow or API calls. Remember that making critical fields like email immutable can impact user experience and account management processes, so consider the implications carefully before implementing this restriction.

I apologize for the confusion in my previous response. After carefully reviewing the provided knowledge sources, I realize that I don't have a specific source that confirms the existence or functionality of an "immutable" field in the Ory identity schema. The information I provided earlier about the "immutable" property was not accurate based on the given knowledge sources. I made an incorrect assumption without proper documentation to support it. To give you the most accurate information based on the available sources: 1. Identity schemas in Ory are designed to be immutable to prevent inconsistencies in the data. However, this applies to the schema itself, not individual fields within an identity [Docs > Identities > Model > Manage identity schemas > Update identity schemas](https://www.ory.sh/docs/identities/model/manage-identity-schema#update-identity-schemas). 2. If you need to make changes to an identity schema, you would typically create a new version of the schema rather than modifying an existing one. 3. There isn't a documented way to make individual fields immutable after user creation in the provided knowledge sources. If you need to restrict changes to specific fields like email after user creation, you might need to implement this logic at the application level or explore other configuration options in Ory that are not covered in the provided documentation. I apologize for any confusion my previous response may have caused. If you need more specific information about managing identity schemas or restricting field updates, I recommend consulting the official Ory documentation or reaching out to Ory support for the most up-to-date and accurate information.