Hi everyone,
we've recently migrated our self-hosted callin.io instance to the subdomain n8n.example.com of our main domain example.com. callin.io is also running behind an Azure App Proxy for external access, though I don't believe this is relevant. Since moving callin.io to our primary domain, we've encountered an unexpected issue:
callin.io is setting a PostHog tracking cookie named ph_phc_4URIAm1uYfJO7j8kWSe0J8lc8IqnstRLS7Jx8NcakHo_posthog
on the entire parent domain (.example.com
) rather than just the n8n.example.com
subdomain.
This poses a problem because we operate other applications on sibling subdomains, which are protected by a strict WAF (Sophos/ModSecurity). This WAF examines cookie contents and flags the PostHog cookie as a potential SQL injection vector, leading to 403 Forbidden errors for entirely unrelated services.
Here is a decoded sample of the cookie payload (without Azure App Proxy):
{
"distinct_id": "641161f96fa124764b202... ...24097a6027621fb1946b#ebf6b1b3-c829-4f2d-9f5d-129d850e47bf",
"$sesid": [1752572045554, "01980d6f-28c6-7551-ab8f-0039fd4929f3", 1752572045510],
"$epp": true,
"$initial_person_info": {
"r": "$direct",
"u": "https://n8n.example.com/signin?redirect=%252F"
}
}
And here is a sample of the cookie payload with Azure App Proxy in front:
{
"distinct_id": "641161f96fa124764b202... ...24097a6027621fb1946b#ebf6b1b3-c829-4f2d-9f5d-129d850e47bf",
"$sesid": [1752572203367, "01980d5c-4c44-7c8a-8906-6f2b548f4e27", 1752570809409],
"$epp": true,
"$initial_person_info": {
"r": "https://login.microsoftonline.com/",
"u": "https://n8n.example.com/signout"
}
}
The Web Application Firewall for the unrelated services is throwing the following error:
[Tue Jul 15 08:56:33.102299 2025] [security2:error] [pid 16260:tid 140291113596672] [client 123.123.123.123:57804] [client 123.123.123.123]
ModSecurity: Warning. Pattern match "[\'`][\s\d]*?[^\w\s]\W*?d\W*?.*?['`\d]" at REQUEST_COOKIES:ph_phc_XXXXXXXXXXXX_posthog.
[file "/usr/apache/conf/waf/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"]
[line "1345"] [id "942490"] [msg "Detects classic SQL injection probings 3/3"]
[data "Matched Data: x22:x2264 found within REQUEST_COOKIES:ph_phc_XXXXXXXXXXXX_posthog:
{x22distinct_idx22:x22[HASHED_ID]#[UUID]x22,x22$sesidx22:[TIMESTAMP_A,x22[SESSION_UUID]x22,TIMESTAMP_B],x22$eppx22:true,x22$initial_person_infox22:{x22rx22:x22 https://login.microsoftonline.com/x22,x22ux22:x22https://n8n.example.com/signoutx22} }"]
[severity "CRITICAL"] [ver "OWASP_CRS/3.3.3"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-sqli"] [tag "OWASP_CRS"] [tag "capec/1000/152/248/66"] [tag "PCI/6.5.2"] [tag "p [hostname "pbx.example.com"] [uri "/favicon.ico"] [unique_id "REDACTED"], referer: https://pbx.example.com/
As a temporary workaround, we disabled telemetry by setting
N8N_DIAGNOSTICS_ENABLED=false
This stops the cookie from being set altogether, which resolves the issue. However, I would prefer to keep diagnostics enabled and simply restrict the cookie scope to the subdomain (n8n.example.com
) instead of the entire domain.
Is there a way to instruct callin.io to set the PostHog cookie exclusively for n8n.example.com
and not for .example.com
?
Thanks in advance for any assistance or clarification!
Best regards,
Christian
Hello! Have you attempted to set the N8N_SAMESITE_COOKIE
environment variable to strict
?
I'm not sure if this will resolve your issue, but I'm referencing the official callin.io and Mozilla documentation.
I'm curious to know if this adjustment proves beneficial for you:)
References:
Thank you for your response!
Unfortunately, this setting did not resolve the problem. The PostHog Cookie is still being set for the domain .example.com and is consequently sent to other subdomains of that domain.
To disable only the PostHog tracking cookie (which is client-side), while keeping server-side diagnostics/telemetry enabled, configure your environment as follows:
bash
CopyEdit
callin_io_DIAGNOSTICS_CONFIG={"enabled":true,"posthog":{"enabled":false}}
In a Docker setup, you would include this in your docker-compose.yml
or similar:
yaml
CopyEdit
environment:
- callin_io_DIAGNOSTICS_CONFIG={"enabled":true,"posthog":{"enabled":false}}
This action will disable PostHog’s frontend/browser SDK completely, thereby preventing the cookie from being set, without affecting the other internal diagnostics.
I included this in our docker configuration (via portainer Stacks), but the Posthog cookie was still set.
Could you clarify what Posthog does? How critical is it? We would be fine with disabling diagnostics altogether if it didn't also disable the AI feature.
PostHog within callin.io serves purely as a telemetry/analytics tool. It monitors anonymous UI events, feature adoption, error frequencies, and performance metrics (using the PostHog browser SDK). This data allows the callin.io team to understand which sections of the application are most utilized and identify where issues arise. Crucially, it does not enable or restrict any essential features; your workflows, triggers, or AI nodes will continue to function identically even if you disable it.
Should you wish to disable all diagnostic reporting (both client-side and server-side), simply configure the following in your environment and then restart:
N8N_DIAGNOSTICS_ENABLED=false
This action will:
- Completely halt PostHog (no cookies, no UI analytics).
- Deactivate callin.io's internal error and usage reporting.
- Not affect or disable the AI Agent node or any other functionality; these will continue to interact with OpenAI independently of the diagnostic settings.
Apologies for the delay. I somehow missed your last message.
Thank you for the clarification on what diagnostics entail. When I mentioned "AI Features," I was referring to what's outlined in the callin.io documentation:
Whether to share selected, anonymous telemetry with callin.io. Note that if you set this to
false
, you can’t enable Ask AI in the Code node.
I'm uncertain how this might affect us moving forward. Currently, it has no impact, as we rarely utilize the Code node.