quick-addition-90714
02/12/2025, 5:55 PMbrief-egg-61061
02/12/2025, 5:55 PMbrief-egg-61061
02/12/2025, 5:56 PMserve.cookies.domain
setting. 3. SameSite Attribute: The SameSite attribute of cookies can affect how they're sent in cross-site requests. The [Ory Hydra Cookies Configuration Guide](https://www.ory.sh/docs/hydra/guides/cookies) mentions that you can configure the SameSite mode using the serve.cookies.same_site_mode
setting. 4. Multiple Cookies: In some cases, Ory might set multiple cookies with similar names. This was reported as an issue in the [Ory Hydra GitHub discussion](https://github.com/ory/hydra/discussions/3834), where multiple ory_hydra_login_csrf_dev
cookies were observed. 5. Cookie Forwarding: When using server-side applications, it's crucial to forward the correct cookies. As mentioned in the [Ory Network GitHub issue](https://github.com/ory/network/issues/36), you need to include the Cookie
header from the client when fetching self-service flows. To troubleshoot your specific issue: 1. Check your cookie configuration in both Hydra and Kratos. 2. Ensure that you're correctly forwarding cookies between your frontend, backend, and Ory services. 3. Inspect the cookies being set and sent using browser developer tools to identify any inconsistencies. If the problem persists, you might want to open an issue on the Ory GitHub repository with more details about your setup and the exact flow you're experiencing issues with. For more detailed troubleshooting, you can refer to the [Ory CSRF Troubleshooting Guide](https://www.ory.sh/docs/troubleshooting/csrf), which provides additional information on dealing with cookie-related issues in Ory services.quick-addition-90714
02/15/2025, 10:26 AMbrief-egg-61061
02/15/2025, 10:26 AMbrief-egg-61061
02/15/2025, 10:26 AMquick-addition-90714
02/22/2025, 3:38 PMbrief-egg-61061
02/22/2025, 3:38 PMbrief-egg-61061
02/22/2025, 3:39 PMyaml courier: delivery_strategy: http http: request_config: url: <https://your-custom-email-service.com> method: POST body: base64://... # You'll need to provide a base64 encoded Jsonnet template headers: Content-Type: application/json
This approach is detailed in the [Send emails using an HTTP server](https://www.ory.sh/docs/kratos/emails-sms/sending-emails-smtp#send-emails-using-an-http-server) section of the Ory documentation. 2. Using a custom SMTP server: Alternatively, you can configure Kratos to use your own SMTP server. This gives you more control over the email sending process. You can set this up as follows: yaml courier: delivery_strategy: smtp smtp: connection_uri: <smtp://username:password@your-smtp-server:port/> from_address: <mailto:noreply@your-domain.com|noreply@your-domain.com> from_name: Your Company Name
This configuration is explained in the [Send emails using your SMTP server](https://www.ory.sh/docs/kratos/emails-sms/sending-emails-smtp#send-emails-using-your-smtp-server) section of the Ory documentation. Both of these methods allow you to handle the actual email sending process yourself, giving you more control over the email content, delivery, and tracking. Remember, when using these custom email delivery methods, you're responsible for ensuring that the emails are sent reliably and securely. You'll also need to handle any email templating on your side. For more detailed information on customizing email delivery in Ory Kratos, you can refer to the [Use a custom server to send Ory Identity messages to users](https://www.ory.sh/docs/kratos/emails-sms/sending-emails-smtp) guide in the Ory documentation.quick-addition-90714
02/22/2025, 3:40 PMbrief-egg-61061
02/22/2025, 3:41 PMbrief-egg-61061
02/22/2025, 3:41 PM--watch-courier
flag, as mentioned in the [Kratos CLI documentation](https://www.ory.sh/docs/kratos/cli/kratos-serve), you should see log entries related to the courier. Look for messages indicating that the courier has started or is processing messages. 2. Monitor the database: The courier processes emails by storing them in an email queue in your database. You can check if this queue is being processed by monitoring the relevant database tables. 3. Check sent emails: If you've configured a test email or have a flow that triggers an email, you can verify if these emails are being sent successfully. 4. Use health checks: Kratos provides health check endpoints. The [Kratos API Reference](https://www.ory.sh/docs/kratos/reference/api) mentions the /health/ready
endpoint, which checks if all system dependencies (including the courier) are functioning correctly. 5. Monitor metrics: If you've enabled metrics, you can check for courier-related metrics. The [kratos courier watch command documentation](https://www.ory.sh/docs/kratos/cli/kratos-courier-watch) mentions an option to expose metrics on a specified port. 6. Check for "Courier sent out message" logs: In the debug logs, you should see entries like "Courier sent out message" when emails are successfully dispatched, as shown in this [GitHub issue](https://github.com/ory/kratos/issues/4161). Remember, for a single-instance setup, the courier runs as a background worker when you use the --watch-courier
flag with the kratos serve
command. As stated in the [Mail courier in self-hosted Ory Kratos documentation](https://www.ory.sh/docs/kratos/self-hosted/mail-courier-selfhosted): "To run the mail courier in the background on your single Kratos instance, add the --watch-courier
flag to your kratos serve
command." If you're not seeing any of these indicators, you might want to check your configuration and ensure that the courier is properly enabled and configured in your single-container setup.quick-addition-90714
02/22/2025, 3:43 PMbrief-egg-61061
02/22/2025, 3:43 PMbrief-egg-61061
02/22/2025, 3:43 PMjsonnet function(ctx) { recipient: ctx.recipient, template_type: ctx.template_type, name: if "template_data" in ctx && "identity" in ctx.template_data && "name" in ctx.template_data.identity then ctx.template_data.identity.name else null, to: if "template_data" in ctx && "to" in ctx.template_data then <http://ctx.template_data.to|ctx.template_data.to> else null, recovery_code: if "template_data" in ctx && "recovery_code" in ctx.template_data then ctx.template_data.recovery_code else null, recovery_url: if "template_data" in ctx && "recovery_url" in ctx.template_data then ctx.template_data.recovery_url else null, verification_url: if "template_data" in ctx && "verification_url" in ctx.template_data then ctx.template_data.verification_url else null, verification_code: if "template_data" in ctx && "verification_code" in ctx.template_data then ctx.template_data.verification_code else null, }
This Jsonnet template is used to generate the payload for HTTP-based email delivery in Ory Kratos. It takes a ctx
(context) object as input and constructs a JSON object with various fields based on the content of the ctx
object. Here's what this template does: 1. It always includes the recipient
and template_type
from the context. 2. It checks for the existence of various fields in the template_data
object and includes them if they exist. 3. It uses conditional statements to handle cases where certain fields might not be present in the context. This template is versatile and can handle different types of email templates (recovery, verification, etc.) by including only the relevant fields for each type. Remember, when using this in your Ory Kratos configuration, you would need to encode it to base64 and include it in your configuration file, as mentioned in the [Using custom message templates](https://www.ory.sh/docs/kratos/emails-sms/custom-email-templates#using-custom-message-templates) documentation.quick-addition-90714
02/23/2025, 2:48 PMbrief-egg-61061
02/23/2025, 2:48 PMbrief-egg-61061
02/23/2025, 2:48 PMcode
): This is the default and recommended method. - Magic links (link
): This is considered a legacy solution and may be deprecated in future releases. As mentioned in the [Account Recovery Documentation](https://www.ory.sh/docs/kratos/self-service/flows/account-recovery-password-reset#supported-recovery-methods), only one method can be enabled at a time. 3. Recovery Address: The system uses the [recovery address defined by the user](https://www.ory.sh/docs/kratos/self-service/flows/account-recovery-password-reset#account-recovery-address) (typically an email address) to send the recovery code or link. 4. Verification: - For the code
method: The user receives a one-time code and enters it on the recovery page. - For the link
method: The user clicks on the magic link sent to their email. 5. Session Creation: Upon successful verification, the user receives a [privileged session](https://www.ory.sh/docs/kratos/session-management/session-lifespan#privileged-sessions). 6. Account Recovery: The user is then directed to their account settings page where they can create a new password to regain access to their account. 7. Flow Completion: After setting a new password, the user regains full access to their account. It's important to note that: - The recovery flow doesn't reset the user's second authentication factor. - For browser applications, there's an automatic redirect to the settings page after recovery. - For native applications, the app must manually take the user to the settings page. The code
method is preferred over the link
method because it avoids issues with email scanners invalidating links and works better for mobile apps and across different devices. For implementation details, you can refer to the [Recovery section in the Ory Kratos API Reference](https://www.ory.sh/docs/kratos/reference/api). This includes endpoints for creating, getting, and updating recovery flows. If you're implementing a custom UI, you'll need to handle the recovery flow in your application. The [Ory Kratos Bring-your-own-ui Integration Basics](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#recovery) guide provides examples of how to create and handle recovery flows in your custom UI. Remember, the exact implementation may vary based on your specific setup and requirements.quick-addition-90714
02/23/2025, 2:49 PMbrief-egg-61061
02/23/2025, 2:49 PMbrief-egg-61061
02/23/2025, 2:49 PM/self-service/recovery
endpoint. Here's an example of how this submission might look, as shown in the [Ory Kratos API Reference](https://www.ory.sh/docs/kratos/reference/api): bash curl -X POST \ -H 'Content-Type: application/json' \ -H 'Accept: application/json' \ -d '{"method":"code","email":"<mailto:user@example.com|user@example.com>","csrf_token":"your-csrf-token"}' \ "https://$<http://PROJECT_SLUG.projects.oryapis.com/self-service/recovery?flow=<your-flow-id|PROJECT_SLUG.projects.oryapis.com/self-service/recovery?flow=<your-flow-id>>"
In this request: - The method
is set to "code" (for the one-time code method). - The email
field contains the user's submitted email address. - A CSRF token is included for security in browser-based flows. 4. Processing the Request: After receiving this request, Ory Kratos will: - Verify the email address. - If the email is associated with an account, send a recovery code or link (depending on your configuration). - If the email is not found, it may still send an email (depending on your configuration) to avoid leaking information about registered accounts. 5. Next Steps: The user then receives the recovery email and proceeds with the rest of the recovery flow as described in the previous answer. So, to directly answer your question: Yes, the user does need to submit their email address to initiate the actual recovery process. The "Forgot Password" link typically just starts the flow and presents the user with the form to enter their email. This approach ensures that recovery attempts are only processed for email addresses that users actually submit, rather than automatically sending emails when someone just clicks a "Forgot Password" link. For more details on implementing this in your UI, you can refer to the [Submit recovery flow](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#submit-recovery-flow) section in the Ory documentation.quick-addition-90714
02/23/2025, 2:53 PMbrief-egg-61061
02/23/2025, 2:53 PMbrief-egg-61061
02/23/2025, 2:53 PM/self-service/recovery/browser
endpoint. This is the correct way to initiate the recovery flow for browser-based applications. According to the [Ory API Reference](https://www.ory.sh/docs/reference/api), the endpoint for creating a recovery flow for browsers is: GET /self-service/recovery/browser
This endpoint initializes a browser-based account recovery flow. When called, it will redirect the browser to the URL specified in your Kratos configuration for selfservice.flows.recovery.ui_url
, with the flow ID set as a query parameter ?flow=
. Here's what happens when this endpoint is called: 1. It creates a new recovery flow instance. 2. It redirects the user to your recovery UI (as specified in your configuration). 3. Your UI can then fetch the flow details and render the appropriate form (usually an email input form). It's important to note that this endpoint is specifically for browser-based flows. As the documentation states: "This endpoint is NOT INTENDED for clients that do not have a browser (Chrome, Firefox, ...) as cookies are needed." If you're implementing a custom UI, you would typically: 1. Have a "Forgot Password" link that, when clicked, navigates to /self-service/recovery/browser
. 2. In your recovery UI page, fetch the flow details using the flow ID from the URL. 3. Render a form where the user can enter their email address. 4. Submit this form to the appropriate Kratos endpoint to continue the recovery process. For more details on implementing this in your custom UI, you can refer to the [Create recovery flow](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#create-recovery-flow) section in the Ory documentation. Remember, if you're building a native application (not browser-based), you would use the /self-service/recovery/api
endpoint instead.quick-addition-90714
02/23/2025, 2:59 PMbrief-egg-61061
02/23/2025, 2:59 PMbrief-egg-61061
02/23/2025, 2:59 PM/self-service/verification/browser
endpoint to initiate a browser-based verification flow. 7. Identity Schema: To make an address verifiable, it must be marked as such in the [identity schema](https://www.ory.sh/docs/kratos/self-service/flows/verify-email-account-activation#identity-schema). This is typically done by adding the verification
property to the email field in the schema. 8. Security Considerations: While verification is important, the documentation notes that it doesn't guarantee the account is used by the person who performed the verification. Additional security measures like TOTP or FIDO2/WebAuthn are recommended for sensitive applications. For more detailed information on implementing and customizing the verification flow, you can refer to the [Email and Phone Verification and Account Activation Documentation](https://www.ory.sh/docs/kratos/self-service/flows/verify-email-account-activation).quick-addition-90714
02/23/2025, 3:00 PMbrief-egg-61061
02/23/2025, 3:00 PMbrief-egg-61061
02/23/2025, 3:00 PMquick-addition-90714
03/08/2025, 1:42 PMbrief-egg-61061
03/08/2025, 1:42 PMbrief-egg-61061
03/08/2025, 1:42 PMkratos.yml
or something similar. 2. In this file, you need to add or modify the session.lifespan
setting. The value for this setting is expressed in hours, minutes, and seconds. Here's an example of how you can set the session lifespan: yaml session: lifespan: 24h
This sets the session length to 24 hours. You can adjust this value according to your needs. For example: - 720h
for 30 days - 1h30m
for 1 hour and 30 minutes - 15m
for 15 minutes 3. After making changes to the configuration file, you need to restart your Kratos service for the changes to take effect. It's important to note that this setting affects the overall session lifespan. There are also other related settings you might want to consider: - `session.cookie.persistent`: This determines whether the session cookie persists after the browser is closed. - `session.earliest_possible_extend`: This sets the earliest time a session can be refreshed. For example: yaml session: lifespan: 720h cookie: persistent: true earliest_possible_extend: 24h
This configuration sets the session to last for 30 days, makes the cookie persistent, and allows the session to be refreshed after 24 hours. For more detailed information on session management and configuration, you can refer to the [Ory Kratos Session Management documentation](https://www.ory.sh/docs/kratos/session-management/session-lifespan). Remember to always consider security implications when setting session lifespans. Longer sessions can be more convenient for users but may also pose increased security risks if a session token is compromised.quick-addition-90714
03/08/2025, 1:45 PMserve:
public:
base_url: <http://localhost:4433/>
selfservice:
default_browser_return_url: <http://localhost:3002/>
allowed_return_urls:
- <http://localhost:3002/>
methods:
password:
enabled: true
flows:
settings:
ui_url: <http://localhost:3002/settings>
verification:
enabled: false
recovery:
enabled: true
ui_url: <http://localhost:3002/recovery>
after:
hooks:
- hook: revoke_active_sessions
logout:
after:
default_browser_return_url: <http://localhost:3002/login>
login:
ui_url: <http://localhost:3002/login>
registration:
enabled: false
error:
ui_url: <http://localhost:3002/error>
log:
level: debug
session:
lifespan: 1m
hashers:
argon2:
parallelism: 1
memory: 128KB
iterations: 2
salt_length: 16
key_length: 16
identity:
schemas:
- id: default
url: file:///etc/config/kratos/identity.schema.json
oauth2_provider:
url: <http://hydra:4445>
it still only expires after one hour?brief-egg-61061
03/08/2025, 1:45 PMbrief-egg-61061
03/08/2025, 1:45 PMyaml session: lifespan: 1m
This setting should make the session expire after one minute, not one hour. The fact that it's expiring after one hour suggests that this configuration might not be applied correctly or there might be other factors at play. 2. Configuration Application: Ensure that the configuration file you've shown is actually being used by your Kratos instance. Sometimes, especially in self-hosted environments, there might be multiple configuration files or environment variables that could override these settings. 3. Restart Requirement: As mentioned in the [Ory Kratos Session Management documentation](https://www.ory.sh/docs/kratos/session-management/session-lifespan), changes to the session configuration require a restart of the Kratos service to take effect. Make sure you've restarted Kratos after changing this configuration. 4. Cookie Settings: The session lifespan can be affected by cookie settings. In your provided configuration, there are no explicit cookie settings. You might want to check if there are any cookie-related configurations elsewhere that could be affecting the session duration. 5. Debugging: Since you've set the log level to debug: yaml log: level: debug
You should be able to see detailed logs about session creation and expiration. Check these logs to see if there are any clues about why the session is lasting longer than expected. 6. Potential Overrides: Check if there are any environment variables or other configuration files that might be overriding this setting. In some deployment scenarios, environment variables can take precedence over configuration file settings. 7. Verification: To verify that the session is indeed expiring after the set time, you can try setting the lifespan to a slightly longer duration (e.g., 5m) and observe if the behavior changes. This can help isolate whether the issue is with the configuration itself or how it's being applied. If after checking these points, the session still expires after one hour, it would be advisable to: 1. Double-check all your configuration files and environment variables. 2. Ensure you're using the latest version of Ory Kratos, as there might have been bug fixes related to session management in newer versions. 3. Consider opening an issue on the [Ory Kratos GitHub repository](https://github.com/ory/kratos) if you believe this might be a bug. Remember, the session lifespan setting should directly affect the duration of the session, so if it's not behaving as expected, there's likely an issue with how the configuration is being applied or a potential bug in the system.quick-addition-90714
03/08/2025, 1:47 PMbrief-egg-61061
03/08/2025, 1:47 PMbrief-egg-61061
03/08/2025, 1:48 PMory update identity-config --project <project-id> --replace '/session/lifespan="1h"'
This command allows you to update the session lifespan directly without editing the configuration file. In this example, it sets the session lifespan to 1 hour. You can adjust the value as needed, using formats like "30m" for 30 minutes, "2h" for 2 hours, or "24h" for 1 day. It's important to note that this command is for use with Ory Network projects. If you're running a self-hosted instance of Kratos, you would typically modify the configuration file directly and restart the service, as mentioned in the [Ory Kratos Session Management documentation](https://www.ory.sh/docs/kratos/session-management/session-lifespan). After running this command, you should verify that the change has been applied successfully. You can do this by checking the current configuration: ory get identity-config --project <project-id>
Remember that changes to session settings typically require a restart of the Kratos service to take effect. If you're using Ory Network, these changes should be applied automatically, but for self-hosted instances, you would need to restart the service manually. [Ory Kratos Session Management documentation](https://www.ory.sh/docs/kratos/session-management/session-lifespan)quick-addition-90714
03/08/2025, 5:45 PMrequired
when in the sent_email
state, which prevents users from using the Resend code
button without first entering a code. But first I wanted to make sure if I wasn't implementing the UI in a wrong waybrief-egg-61061
03/08/2025, 5:45 PMbrief-egg-61061
03/08/2025, 5:45 PMsent_email
state, the UI nodes include a code
input field that is marked as required
. 2. This required
attribute on the code
field prevents users from using the "Resend code" button without first entering a code, which is not the intended behavior. This behavior is confirmed in the example JSON response provided in the issue, where the code
input node has the required
attribute set to `true`: json { "type": "input", "group": "code", "attributes": { "name": "code", "type": "text", "required": true, "disabled": false, "node_type": "input" }, "messages": [], "meta": { "label": { "id": 1070010, "text": "Recovery code", "type": "info" } } }
The issue reporter notes that this leads to a poor user experience, as users cannot resend the code without first entering a value in the code field. To address this in your UI implementation, you might consider: 1. Ignoring the required
attribute for the code input field when rendering the "Resend code" button. 2. Implementing client-side logic to allow the "Resend code" action without requiring the code field to be filled. However, it's important to note that this is a known issue in Kratos itself, and the ideal solution would be for it to be fixed at the Kratos level. You might want to follow or contribute to the GitHub issue for updates on this problem. For now, implementing a workaround in your UI is a valid approach to improve the user experience while waiting for an official fix from the Ory team. [Incorrect UI Node Grouping For Recovery Flow](https://github.com/ory/kratos/issues/3980)