Certainly! In self-hosted Ory Kratos, you can configure a web hook to fire after a user successfully logs in by adding a hook to the

after

login flow in your configuration file. Here’s an example configuration snippet for such a web hook:

yaml selfservice:   flows:     login:       after:         hooks:           - hook: web_hook             config:               url: <https://your-webhook-endpoint.example.com/after-login>               method: POST               body: <base64://ENCODED_JSONNET> # Optional: customize the payload               response:                 ignore: false                 parse: false               auth:                 type: api_key                 config:                   name: Authorization                   value: YOUR_API_KEY                   in: header

- The

hook: web_hook

entry tells Kratos to trigger a webhook. - The

url

is your endpoint that will receive the POST request after a successful login. - You can customize the request body using a base64-encoded Jsonnet template. - Authentication options (like API key) are available for securing your webhook endpoint. This configuration ensures your external system is notified every time a user logs in successfully. For more details and options, see the [Ory webhooks documentation](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks) and the [available actions in hooks](https://www.ory.sh/docs/kratos/hooks/configure-hooks#available-actions)<source>https://www.ory.sh/docs/kratos/hooks/configure-hooks#available-actions&lt;/source&gt;&lt;source&gt;https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks&lt;/source>.

When configuring a Kratos webhook, the information available to include in the webhook message (the request body) can be customized using a Jsonnet template. The available context for the webhook includes: - identity: The full identity object of the user involved in the flow. - flow: The flow object, which contains details about the current self-service flow (e.g., login, registration). - request_url: The URL that initiated the flow. - request_headers: The HTTP headers from the original request. - request_cookies: The cookies from the original request. - request_method: The HTTP method used in the original request. For password migration webhooks, additional fields like

identifier

and

password

are available, but for general login/registration webhooks, the above context is standard. You can use these fields to construct a custom payload for your webhook endpoint. If you do not provide a custom body, Kratos will send a default payload containing relevant information about the event<source>https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#customizing-request-body-with-jsonnet&lt;/source&gt;&lt;source&gt;https://www.ory.sh/docs/kratos/manage-identities/import-user-accounts-identities#password-migration-using-a-web-hook&lt;/source>. For more details and examples on customizing the request body, see the [webhook documentation](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#customizing-request-body-with-jsonnet).

Sorry @plain-lunch-50969, I'm currently experiencing some technical difficulties. Please try again in a few minutes. If this issue persists, please reach out to the administrators of this Slack workspace.

Based on the knowledge sources, here are the most likely reasons why your webhook is not being called and nothing appears in the logs: 1. Method-Specific Hook Precedence: If you have method-specific hooks configured (e.g.,

password

,

oidc

, etc.) under

login.after

, these will override the global

after.hooks

section. In such cases, the global hook will not be triggered for those methods. You should check your full configuration to ensure there are no method-specific hooks that might be taking precedence over the global one. This behavior is described in the [trigger precedence documentation](https://www.ory.sh/docs/kratos/hooks/configure-hooks#trigger-precedence)<source>https://www.ory.sh/docs/kratos/hooks/configure-hooks#trigger-precedence&lt;/source>. 2. No Log Output: The knowledge sources do not provide explicit details about logging for failed or skipped hooks in self-hosted Kratos. If the hook is not being triggered due to configuration precedence or other issues, it is possible that nothing will appear in the logs. 3. Webhook URL Formatting: If your webhook URL contains leading or trailing whitespace, the webhook may silently fail to be registered or called. This has been reported as a real-world issue and can result in no webhook calls and no clear error messages in the logs. Double-check your URL formatting to ensure there are no hidden characters or spaces. This issue is discussed in [this GitHub issue](https://github.com/ory/network/issues/328)<source>https://github.com/ory/network/issues/328&lt;/source>. 4. General Troubleshooting: The documentation suggests exporting your configuration and reviewing the order and placement of hooks, especially if you have other hooks like

session

that could interfere with execution order. However, your provided snippet does not include a

session

hook, so this is less likely the cause in your case<source>https://www.ory.sh/docs/troubleshooting/troubleshoot-actions&lt;/source>. Summary: - Check for method-specific hooks that may override the global

after.hooks

. - Ensure your webhook URL is correctly formatted with no extra spaces. - If the above do not resolve the issue, the knowledge sources do not provide further explicit troubleshooting steps for this scenario. If you need more detailed troubleshooting, consider exporting your full configuration and reviewing it for any discrepancies as suggested in the documentation.

The error "got empty template path for request with body" indicates that Ory Kratos expects a request body for your webhook, but you have not specified a

body

field in your configuration. According to the documentation, the

body

field is optional, and if not specified, Kratos should use a default payload. However, in some cases—especially when using certain HTTP methods like `POST`—Kratos may require an explicit body template to be set, or it may not be able to determine what to send and thus fails with this error. To resolve this, you should explicitly specify a body for your webhook. You can use a simple Jsonnet template, for example:

yaml body: <file://path/to/body.jsonnet>

Or, if you want to use the default payload, you can use a universal Jsonnet template like:

jsonnet function(ctx) { user_id: ctx.identity.id }

Encode this template as a file or as a base64 string and reference it in your configuration:

yaml body: base64://<base64-encoded-jsonnet>

This approach is confirmed in the documentation, which shows that the

body

field can be omitted, but if you encounter this error, specifying it explicitly resolves the issue [see webhook configuration and Jsonnet templating](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#define-http-request)<source>https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#define-http-request&lt;/source>. If you continue to see this error after specifying a body, there may be an issue with how the path or encoding is provided. Double-check the path or base64 encoding as needed.

You can find the official Jsonnet documentation and learning resources at [https://jsonnet.org/](https://jsonnet.org/). Ory also recommends checking out the [Learning Jsonnet Tutorial](https://jsonnet.org/learning/tutorial.html) for a practical introduction and examples relevant to Ory Kratos configuration and data mapping [Data mapping with Jsonnet](https://www.ory.sh/docs/kratos/reference/jsonnet)<source>https://www.ory.sh/docs/kratos/reference/jsonnet&lt;/source>.

I'm sorry, but the knowledge sources do not explicitly mention a built-in or simple way to dump the full

ctx

object when executing a post-login webhook in Ory Kratos. The documentation describes the structure and available fields of

ctx

and how to use Jsonnet to access them, but it does not provide a direct method or example for dumping or logging the entire

ctx

object during webhook execution. If you need to inspect the contents of

ctx

, you could create a Jsonnet template that includes all fields you are interested in and send them to your webhook endpoint, but this would require you to manually specify which fields to include. There is no mention of a "dump all" or debug mode for webhooks in the provided documentation sources [Jsonnet templating](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#jsonnet-templating)<source>https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#jsonnet-templating&lt;/source>. If you need further assistance, you may need to experiment by constructing a Jsonnet template that outputs as much of

ctx

as possible, or consult Ory community channels for advanced debugging techniques.

The knowledge sources do not provide an explicit example or confirmation that using a Jsonnet template like

'function(ctx) { Text: "ctx" + ctx }'

will successfully dump the entire

ctx

object in the webhook payload. Jsonnet does allow you to construct objects from the

ctx

parameter, and you can include fields from

ctx

in your output, but directly concatenating an object to a string (as in

"Text: " + ctx

) is not valid Jsonnet syntax and will result in an error. To inspect the contents of

ctx

, you should return it directly or as a field in your Jsonnet template, for example:

jsonnet function(ctx) { ctx: ctx }

This will include the entire

ctx

object in the webhook payload, allowing you to see all available fields. For more details on how to use Jsonnet with Ory webhooks, see the [Jsonnet templating documentation](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#jsonnet-templating)<source>https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#jsonnet-templating&lt;/source>. If you need to inspect specific fields, you can construct an object with just those fields from

ctx

.

Yes, you can call unauthenticated webhooks via HTTP in Ory Kratos. The webhook configuration allows you to omit the

auth

section, which means no authentication will be used for the webhook request. Additionally, the

url

can use either the

http://

or

https://

scheme, as long as it is an absolute URL and includes a path part. This is explicitly mentioned in the configuration documentation for HTTP-based email delivery, which applies similarly to webhooks: > It needs to be absolute, start with http:// or https:// scheme, and include path part - for example "https://api.sender.com/v1/message". If you do not specify authentication, the webhook will be called unauthenticated [source](https://www.ory.sh/docs/kratos/self-hosted/email-http#configuration). However, please note that using unauthenticated and unencrypted (HTTP) webhooks in production is not recommended for security reasons.

Based on the knowledge sources, there is no explicit documentation about Kratos webhooks hanging in a Kubernetes (k8s) environment when the same webhook works with

curl

. However, there are a few relevant points and troubleshooting steps you should consider: 1. Private IP Range Restrictions: If you have enabled the

disallow_private_ip_ranges

setting in your Kratos configuration, Kratos will block outgoing HTTP requests to private IP ranges, which includes services within the same Kubernetes namespace. This could cause the webhook call to hang or fail. Check your configuration for:

yaml    clients:      http:        disallow_private_ip_ranges: true

If this is set to

true

, try disabling it or ensure your internal service is accessible according to your security requirements [see production guide](https://www.ory.sh/docs/kratos/guides/production). 2. No Explicit Logging or Error: The knowledge sources do not mention specific log messages for this scenario. If Kratos is hanging, it may be waiting for a network timeout or being blocked by network policies or service mesh configurations in your cluster. 3. General Troubleshooting: - Ensure the service DNS name and port are correct and accessible from the Kratos pod. - Check for any network policies, service mesh, or firewall rules that might block traffic between pods. - Review Kratos logs for any warnings or errors related to HTTP client requests. If none of these apply and the issue persists, the knowledge sources do not provide further explicit guidance for this scenario. You may need to increase logging verbosity or use network debugging tools within your cluster to further diagnose the issue.