CSRF Verification Failed

[francesco-larghi-duferco]

Self-Hosted Version

24.2.0

CPU Architecture

x86_64

Docker Version

25.0.1

Docker Compose Version

2.24.2

Steps to Reproduce

• Created AWS EC2 Ubuntu 22.04 machine
• Install docker and docker compose
• Install self hosted Sentry following the instructions and creating superuser
• Run docker compose up -d
• Open https://my-local-ip:9000 and login with the created user
• CSRF Verification Failed

Expected Result

Logging in the Web interface.

Actual Result

I'm probably missing some key step, not clear which one.

Event ID

No response

[vadim-vin]

Hello, same problem here.

[DaveKeehl]

+1

[vadim-vin]

https://develop.sentry.dev/self-hosted/

Once you have setup a load balancer or reverse proxy to your Sentry instance, you should modify the system.url-prefix in the config.yml file to match your new URL and protocol. You should also update the SSL/TLS section in the sentry/sentry.conf.py script, otherwise you may get CSRF-related errors when performing certain actions such as configuring integrations.

[francesco-larghi-duferco]

https://develop.sentry.dev/self-hosted/

Once you have setup a load balancer or reverse proxy to your Sentry instance, you should modify the system.url-prefix in the config.yml file to match your new URL and protocol. You should also update the SSL/TLS section in the sentry/sentry.conf.py script, otherwise you may get CSRF-related errors when performing certain actions such as configuring integrations.

Thank you for the insight, but i receive the same error even without having reverse proxy in front of Sentry (Nginx or AWS ALB).
My idea is to eventually use them, but also just for testing purposes if I type in the private IP of the machine on port 9000, without having other reverse proxy running on the machine, I still got the same error.

Should I try directly configuring the subdomain, certificates and reverse proxy and changing accordingly the configuration? I was excepting it to work without it for testing.

[vadim-vin]

hi @francesco-larghi-duferco
I set system.url-prefix: to the machine's actual IP address and port (I also don't have any proxy) in sentry/config.yml and it appears to start working.

[francesco-larghi-duferco]

hi @francesco-larghi-duferco I set system.url-prefix: to the machine's actual IP address and port (I also don't have any proxy) in sentry/config.yml and it appears to start working.

Hello again! Yes, you are right.
Nevertheless, it's not clear to me why. Is it a bug maybe? It looks like that field should be assigned only in case of domain changes or reverse proxy indeed.
Anyway thanks for your help on that!

[1021683053]

hi @francesco-larghi-duferco I set system.url-prefix: to the machine's actual IP address and port (I also don't have any proxy) in sentry/config.yml and it appears to start working.

Thank you.You were right.

[hubertdeng123]

Is everyone here using the nightly image of self-hosted Sentry? Meaning 24.2.0.dev?

[aldy505]

hi @francesco-larghi-duferco I set system.url-prefix: to the machine's actual IP address and port (I also don't have any proxy) in sentry/config.yml and it appears to start working.

Hello again! Yes, you are right.

Nevertheless, it's not clear to me why. Is it a bug maybe? It looks like that field should be assigned only in case of domain changes or reverse proxy indeed.

Anyway thanks for your help on that!

Ah perhaps I need to make the docs more clearer. Thanks for finding this out!

[francesco-larghi-duferco]

Is everyone here using the nightly image of self-hosted Sentry? Meaning 24.2.0.dev?

Yes I am specifically using it 👍

[aldy505]

Okay so.. it turns out this also happens on 24.1.1, where I'm running my sentry instance behind a reverse proxy.

The system.url-prefix is set to the IP of the server (in this case it's 10.100.31.77). On my reverse proxy configuration, I have a few settings that enables me to access my Sentry via these addresses:

• https://10.100.31.77
• https://sentry.internal.company.com (TLS terminated by the reverse proxy, private only, can see dashboard and everything)
• https://sentry.ingest.company.com (TLS terminated by the reverse proxy, publicly available, only ingest endpoints)

I can access Sentry via https://10.100.31.77, but not via every other domain. This didn't happen with previous releases.

[hubertdeng123]

We've recently upgraded to Django 4 in the main sentry repo, and we've observed that there are more strict CSRF rules there. So, I put up this PR to try to fix that for the majority of folks:
getsentry/sentry#63908

If you're on a more complex setup, it might help to set the CSRF_TRUSTED_ORIGINS yourself in the sentry.conf.py file

[theremoon-j]

+1

same to me

[aldy505]

Hey @kid-of-moon, try to modify your sentry/sentry.conf.py file as shown here https://github.com/getsentry/self-hosted/pull/2762/files (the PR's still pending)

[hongquan]

The fix is to open sentry/config.yml file and set system.url-prefix to match your public URL.

[1021683053]

We've recently upgraded to Django 4 in the main sentry repo, and we've observed that there are more strict CSRF rules there. So, I put up this PR to try to fix that for the majority of folks:我们最近在主哨兵存储库中升级到了 Django 4，并且我们观察到那里有更严格的 CSRF 规则。因此，我提出这个 PR 来尝试为大多数人解决这个问题： getsentry/sentry#63908 获取哨兵/哨兵#63908

If you're on a more complex setup, it might help to set the CSRF_TRUSTED_ORIGINS yourself in the sentry.conf.py file如果您的设置更复杂，那么在sentry.conf.py 文件中自行设置 CSRF_TRUSTED_ORIGINS 可能会有所帮助

You're right, too.

[theremoon-j]

system.url-prefix
It doesn't work for me.
can i avoid this issue if user sentry version before 23.12.1

[aldy505]

system.url-prefix
It doesn't work for me.
can i avoid this issue if user sentry version before 23.12.1

@kid-of-moon Have you configure your sentry.conf.py file to include CSRF_TRUSTED_ORIGINS variables? Have you run ./install.sh after modifying the file? If you have and that still didn't work, can I see the value on that specific variable?

[chadwhitacre]

Are we calling this good with #2762? Do we want to do more here?

[hubertdeng123]

I think we can close as this should be mostly resolved with getsentry/sentry#63908 and getsentry/sentry#64473. For nonstandard setups, people can specify the CSRF_TRUSTED_ORIGINS option themselves.

[Sweet-KK]

I tried all of the above methods and updated the code, but in the end it was resolved by falling back to 23.12.1

[theremoon-j]

I tried all of the above methods and updated the code, but in the end it was resolved by falling back to 23.12.1

yes, it's the only correct way for me either.