OAUTH callback URL not accurate despite site domain set

[Coolguy3289]

Describe the issue

Once switching domains to a .app domain (which forces SSL), I had to reconfigure weblate to use HTTPS, once finally getting the site to load correctly, the issue I'm left remaining is when trying to auth through Github, the callback URL is the domain of the server, not the WEBLATE_SITE_DOMAIN set in the docker-compose.override file

I already tried

• [ X] I've read and searched the docs and did not find the answer there.
  If you didn’t try already, try to search there what you wrote above.
  I've tried tweaking the reverse proxy settings in the apache2 vhost config

To Reproduce the issue

Steps to reproduce the behavior:

1. Spin up a docker instance of weblate, configured to use Github Oauth
2. Enable HTTPS and proxy behind apache2
3. Attempt to auth via Github
4. See error

Expected behavior

Expected to show the github login screen.

Screenshots

https://cdn.discordapp.com/attachments/484164647830945793/870166332920971264/unknown.png

Exception traceback

No useful info in docker logs, even with debug on.

Server configuration and status
Apache2 vhost config:

<VirtualHost *:443> 
ServerAdmin admin@translate.tacobot.app
ServerName translate.tacobot.app
SSLProxyEngine on
SSLCertificateFile /etc/letsencrypt/live/translate.tacobot.app/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/translate.tacobot.app/privkey.pem
SSLProxyVerify none
SSLProxyCheckPeerCN off 
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off 
#ProxyPreserveHost on
RequestHeader set X-Forwarded-Proto https
RequestHeader set X-Real-IP 23.182.16.10
#RequestHeader set X-Forwarded-For $proxy_add_x_forwarded_for
RequestHeader set X-Forwarded-Host translate.tacobot.app                                                                                                                                                                                     ProxyPass "/" "https://localhost:4443/"
ProxyPassReverse "/" "http://localhost:4443/" 
</VirtualHost>

docker-compose.override.yml:

version: '3'
services:
weblate:
ports: 
 - 8000:8080
 - 4443:4443
environment: 
 WEBLATE_SITE_DOMAIN: translate.tacobot.app
 WEBLATE_EMAIL_HOST:
 WEBLATE_EMAIL_HOST_USER:
 WEBLATE_EMAIL_HOST_PASSWORD: 
 WEBLATE_SERVER_EMAIL: translate@tacobot.app
 WEBLATE_DEFAULT_FROM_EMAIL: translate@tacobot.app
 WEBLATE_ALLOWED_HOSTS: translate.tacobot.app,localhost
 WEBLATE_ADMIN_EMAIL: contact@tacobot.app
 WEBLATE_DEBUG: 1
 WEBLATE_SITE_TITLE: Taco Translations 
 WEBLATE_TIME_ZONE: America/New_York 
 WEBLATE_SOCIAL_AUTH_GITHUB_KEY: 
 WEBLATE_SOCIAL_AUTH_GITHUB_SECRET:
 WEBLATE_ENABLE_HTTPS: 1
 WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR

Server Versions:
https://hastebin.com/ximanimicu.yaml

settings-override.py in docker data volume:
CSRF_TRUSTED_ORIGINS = ["translate.tacobot.app"]
Weblate deploy checks

System check identified some issues:

WARNINGS:
?: (security.W018) You should not have DEBUG set to True in deployment.

INFOS:
?: (weblate.I021) Error collection is not set up, it is highly recommended for production use
        HINT: https://docs.weblate.org/en/weblate-4.7.2/admin/install.html#collecting-errors
?: (weblate.I028) Backups are not configured, it is highly recommended for production use
        HINT: https://docs.weblate.org/en/weblate-4.7.2/admin/backup.html

System check identified 3 issues (1 silenced).

[github-actions]

This issue looks more like a support question than an issue. We strive to answer these reasonably fast, but purchasing the support subscription is not only more responsible and faster for your business but also makes Weblate stronger.

In case your question is already answered, making a donation is the right way to say thank you!

[nijel]

Isn't this configured at GitHub side?

[Coolguy3289]

Github's side of things is more the check, if what Weblate sends isn't matched to what's on Github's config, then it'll toss an error. The issue is that weblate seems to be sending not only the wrong URL, but malformed as well. The URL being sent is thegamingcorner.net with no trailing / so the URL isn't even resolvable even tho its wrong.

[Coolguy3289]

I feel like it has to have something to do with the docker side of things and/or the proxy through apache. But I'm only guessing, I don't work much with Docker in general.

[Coolguy3289]

I'm going to just silently close this. For those interested, @nijel was correct, it was the GitHub side of things. I had a personal and org level application, one of which wasn't being used but was the one I changed and the org level one is what I forgot about. The issue I was facing was the old callback URL being used and hitting no valid domain in my apache configs so it was redirecting to my default domain as it is configured to do.

[github-actions]

The issue you have reported is now resolved. If you don’t feel it’s right, please follow its labels to get a clue for further steps.

• In case you see a similar problem, please open a separate issue.
• If you are happy with the outcome, don’t hesitate to support Weblate by making a donation.