CSRF verification failed. Request aborted

[thka-trifork]

Describe the issue

I have deployed weblate on a AKS cluster through the helm chart, together with nginx ingress controller and letsencrypt. So far everything works, the only thing is every POST command does not seem to work because of CSRF resulting in a error:

Permission Denied
CSRF verification failed. Request aborted.
CSRF failure reason: Origin checking failed - https://translate.dev.xyz.com does not match any trusted origins.

I have set the following parameters in the helm chart:

• extraConfig.CSRF_TRUSTED_ORIGINS: "[https://translate.dev.xyz.com,http://translate.dev.xyz.com,https://.dev.xyz.com,https://.dev.xyz.com,https://translate.dev.xzy.com/accounts/login/azuread-tenant-oauth2/]"

•     siteDomain: "translate.dev.xzy.com"
  

•     allowedHosts: "translate.dev.xyz.com"
  

However nothing seems to get passed the CSRF verfication. Neither with azure authentication nor with plain password authentication.

Host and side-domain match from what I can see.

I already tried

• I've read and searched the documentation.
• I've searched for similar filed issues in this repository.

Steps to reproduce the behavior

1. Deploy weblate on AKS with helm chart version 0.5.25
2. go to login, try to login via azure or with username password

Expected behavior

There should not be CSFR error request and the login should return success on correct password

Screenshots

No response

Exception traceback

10.244.2.7 - - [15/Oct/2025:12:28:35 +0000] "GET /static/prism-weblatesearch.js?v=5.13.3 HTTP/1.1" 200 318 "https://translate.dev.xyz.com/" "useragent"
Forbidden (Origin checking failed - https://translate.dev.xyz.com does not match any trusted origins.): /accounts/login/

Additional context

Ingress configuration looks like:

ingress:
enabled: true
ingressClassName: nginx
hosts:
- host: translate.dev.xyz.com
paths:
- path: /
pathType: Prefix
tls:
- secretName: weblate-tls
hosts:
- translate.dev.xyz.com

[nijel]

This error is usually caused by wrong Host header passed by reverse proxy (ingress), see https://docs.weblate.org/en/latest/admin/install.html#running-behind-reverse-proxy

[thka-trifork]

Hi, I double checked the Host and it should be fine. Is there any documentation or recommendation on how to configure ingress with NGINX Ingress Controller?

Is there a way to get more insights in what exactly happens and where does it fail exactly? Maybe I misconfiguration some env variables but I am not aware of them?

[Hechamon]

I'm having the same issue with my installation, but only after upgrading to helm chart version 0.5.25.
0.5.23 and 0.5.24 work without issues.

[thka-trifork]

@Hechamon Thanks for that info. Pretty interesting because there should not be any change regarding ingress with this change according to the changelog in the helm chart itself:
https://artifacthub.io/packages/helm/weblate/weblate/0.5.25?modal=template&template=secret.yaml&compare-to=0.5.23
But the application version changed from 5.11.3 to 5.13.3 and the most notably change is this:

Docker container is now using granian. This now requires explicit configuration of proxy trusted headers including client protocol. See [Running behind reverse proxy](https://docs.weblate.org/en/weblate-5.13/admin/install.html#reverse-proxy).

So I can login now with the admin user however azure sso login does not work because the callback url created does not include ssl. Do you maybe happen to have some configuration for things like that? I think there should be some configuration examples in the documentation for this.

[Hechamon]

I'm running Weblate on a Openshift cluster, so we're not using the standard Ingress but a Route instead.
But the route does do the ssl termination, so it's very possible that I have to set the WEBLATE_SECURE_PROXY_SSL_HEADER header to fix this.
@thka-trifork Thank you for the link, I'll update this issue in the coming days when I have time to re-try the upgrade.

[nijel]

WeblateOrg/weblate#16671 will make debugging such things easier.

[Mart-Kuc]

Hi @thka-trifork, it looks like you are missing prefix for your env CSRF_TRUSTED_ORIGINS in extraConfig.

I think it should include the prefix WEBLATE so use: WEBLATE_CSRF_TRUSTED_ORIGINS.

Also you might be running into another issue related to missing SSL_HEADER. So WEBLATE_SECURE_PROXY_SSL_HEADER and WEBLATE_IP_PROXY_HEADER will be probably needed

[thka-trifork]

@Mart-Kuc Thank you so much, yes indeed CSRF_TRUSTED_ORIGINS was missing in extraConfig. I also downgraded now to helm chart version 0.5.23 and specifically set the version through the values to 5.12.2.3@sha256:4d1b59033cb54fdbb9183c2ce1d264c4e9f7751c4d0335292199bc555c1a223a This would probably not be necessary but we used that in a different setup and the database migration caused some trouble too.

I also set WEBLATE_ENABLE_HTTPS to make sure the httpS redirect of the azure works. Other than that this seems to work now. But I did not try the newest version.

[Hechamon]

I managed to get my installation working with the newest version, my final config is at the bottom.
What took me a long time to realize is the fact that the Header names are prefixed with HTTP_ and all caps for some reason. The header from the reverse proxy are actually x_forwarded_proto for example.
Also, make sure to realize that not all config can be set via env variables, some need to be injected in the python configOverride

# configOverride -- Config override. See https://docs.weblate.org/en/latest/admin/install/docker.html#custom-configuration-files
  configOverride: |
    IP_BEHIND_REVERSE_PROXY = True
    SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")

  extraConfig:
    WEBLATE_IP_PROXY_HEADER: "HTTP_X_FORWARDED_FOR"
    WEBLATE_ENABLE_HTTPS: "1"

[github-actions]

This issue has been automatically marked as stale because there wasn’t any recent activity.

It will be closed soon if no further action occurs.

Thank you for your contributions!