search

PostHog / posthog

🦔 PostHog provides open-source product analytics, session recording, feature flagging and A/B testing that you can self-host.
https://posthog.com
Other
20.57k stars 1.22k forks source link

CSP: `Blocked 'connect' from 'eu.i.posthog.com'` #20461

Open MathiasWP opened 6 months ago

MathiasWP commented 6 months ago

Bug description

We've received over 500+ errors over the last 2 hours in Sentry about Blocked 'connect' from 'eu.i.posthog.com'

What is this change, and where does it come from? Is https://eu.posthog.com deprecated? Please describe.
If this affects the front-end, screenshots would be of great help.

If you are on PostHog Cloud it would be really valuable if you can share any links where the problem occurs. This speeds up our ability to troubleshoot tremendously.

How to reproduce

  1. Set CSP to connect-src https://eu.posthog.com

Environment

Additional context

Thank you for your bug report – we love squashing them!

rafabernardo commented 6 months ago

I'm having the same problem here but with US server...

did you managed to fix @MathiasWP?

neilkakkar commented 6 months ago

Hi both,

eu.i.posthog.com and us.i.posthog.com are supported domains where we route API requests to now. Please add these to your CSP directives and it should be fine.

MathiasWP commented 6 months ago

Hi both,

eu.i.posthog.com and us.i.posthog.com are supported domains where we route API requests to now. Please add these to your CSP directives and it should be fine.

But why are requests sent to us.i.posthog.com when we're using the EU based dashboard?

MarconLP commented 6 months ago

Hi both, eu.i.posthog.com and us.i.posthog.com are supported domains where we route API requests to now. Please add these to your CSP directives and it should be fine.

But why are requests sent to us.i.posthog.com when we're using the EU based dashboard?

You only need to send the events to one of those domains:

benjackwhite commented 6 months ago

Just to clarify here:

We often need to make changes to routing of traffic to account for a range of developments from performance improvements to CDNs etc. As such we would recommend setting a relatively permissive CSP configuration such as *.posthog.com.

For example we are migrating to eu.i.posthog.com as adblockers were triggering issues with running our web application. In addition we will serve some things from eu-assets.i.posthog.com such as runtime JS assets.

I'll make sure to get a document added to posthog.com documenting this.

MathiasWP commented 6 months ago

Hi both, eu.i.posthog.com and us.i.posthog.com are supported domains where we route API requests to now. Please add these to your CSP directives and it should be fine.

But why are requests sent to us.i.posthog.com when we're using the EU based dashboard?

You only need to send the events to one of those domains:

  • us.i.posthog.com for the US Cloud
  • eu.i.posthog.com for the EU Cloud

I don't specify where we send the events, that's done by PostHog.

Our CSP detects connections to us.i.posthog.com when we're using the EU cloud, which shouldn't be expected... right?

MarconLP commented 6 months ago

Hi both, eu.i.posthog.com and us.i.posthog.com are supported domains where we route API requests to now. Please add these to your CSP directives and it should be fine.

But why are requests sent to us.i.posthog.com when we're using the EU based dashboard?

You only need to send the events to one of those domains:

  • us.i.posthog.com for the US Cloud
  • eu.i.posthog.com for the EU Cloud

I don't specify where we send the events, that's done by PostHog.

Our CSP detects connections to us.i.posthog.com when we're using the EU cloud, which shouldn't be expected... right?

That shouldn't be the case. Do see network requests to both the EU and US Cloud? In that case, you might be loading PostHog twice.

amitav13 commented 6 months ago

Just to clarify here:

We often need to make changes to routing of traffic to account for a range of developments from performance improvements to CDNs etc. As such we would recommend setting a relatively permissive CSP configuration such as *.posthog.com.

For example we are migrating to eu.i.posthog.com as adblockers were triggering issues with running our web application. In addition we will serve some things from eu-assets.i.posthog.com such as runtime JS assets.

I'll make sure to get a document added to posthog.com documenting this.

We're actually facing the reverse in terms of ad blockers - Ublock origin is blocking eu.i.posthog where it was fine earlier :(

We're trying to migrate to using a proxy in a hurry now, our volume of session replays has gone down.

Updating a CSP isn't an option for us since we have a chat widget that's deployed on our client's websites.

rafabernardo commented 6 months ago

I added .posthog.com, us.i.posthog.com, and .i.posthog.com, yet I still encountered errors of being blocked on Sentry. Consequently, I had to disable reply and event collection to prevent reaching my limit on Sentry.

grahamc commented 6 months ago

Just a note that https://posthog.com/docs/session-replay/troubleshooting suggests adding only app.posthog.com.