Fix Redirect URL Generation for Google Auth by Enabling X-Forwarded-Host #7067
Conversation
WalkthroughA new configuration setting, Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
Note 🔌 MCP (Model Context Protocol) integration is now available in Early Access!Pro users can now connect to remote MCP servers under the Integrations page to get reviews and chat conversations that understand additional development context. ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
|
![coderabbitai[bot]](https://cdn.statically.io/img/avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
apps/api/plane/settings/common.py (2)
475-476: Harden proxy handling to prevent header spoofingUSE_X_FORWARDED_HOST trusts the upstream proxy to supply X-Forwarded-Host. Ensure:
- Your reverse proxy strips client-supplied X-Forwarded-Host and sets it explicitly (e.g., Nginx: proxy_set_header X-Forwarded-Host $host;).
- ALLOWED_HOSTS includes only the expected external domains in production (current default "*" is permissive and may mask misconfigurations).
Would you like a short checklist/snippet for Nginx/Ingress to ensure these headers are set and sanitized?
475-476: Add a test to lock this behavior for the Google OAuth start endpointRecommend a test that:
- Sets USE_X_FORWARDED_HOST=True (override_settings).
- Calls the OAuth initiation endpoint with HTTP_X_FORWARDED_HOST set to the external domain and HTTP_X_FORWARDED_PROTO=https.
- Asserts the redirect Location uses the external domain and https scheme.
I can draft the test tailored to your OAuth view if you share the URL name or view function.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/api/plane/settings/common.py(1 hunks)
🔇 Additional comments (1)
apps/api/plane/settings/common.py (1)
475-476: Enabling X-Forwarded-Host aligns with the OAuth redirect host fixThis directly addresses the host-mismatch by letting Django honor X-Forwarded-Host from your reverse proxy. Good change.
| # Use X-Forwarded-Host for get_host calls when behind proxy | ||
| USE_X_FORWARDED_HOST = int(os.environ.get("USE_X_FORWARDED_HOST", 0)) == 1 |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Also set SECURE_PROXY_SSL_HEADER to fix the scheme (https) behind a TLS-terminating proxy
Without this, build_absolute_uri may still generate http URLs even though the external URL is https, causing OAuth redirect mismatches. Tie it to the same flag to avoid surprising dev environments.
Apply this minimal diff after Line 476:
USE_X_FORWARDED_HOST = int(os.environ.get("USE_X_FORWARDED_HOST", 0)) == 1
+
+# Honor X-Forwarded-Proto for correct scheme when behind a TLS-terminating proxy
+if USE_X_FORWARDED_HOST:
+ SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")If you terminate TLS at the proxy and forward requests over HTTP to Django, this ensures request.is_secure() is True and absolute URLs use https.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # Use X-Forwarded-Host for get_host calls when behind proxy | |
| USE_X_FORWARDED_HOST = int(os.environ.get("USE_X_FORWARDED_HOST", 0)) == 1 | |
| # Use X-Forwarded-Host for get_host calls when behind proxy | |
| USE_X_FORWARDED_HOST = int(os.environ.get("USE_X_FORWARDED_HOST", 0)) == 1 | |
| # Honor X-Forwarded-Proto for correct scheme when behind a TLS-terminating proxy | |
| if USE_X_FORWARDED_HOST: | |
| SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https") |
🤖 Prompt for AI Agents
In apps/api/plane/settings/common.py at lines 475-476, you need to set the
SECURE_PROXY_SSL_HEADER setting to ensure Django correctly identifies HTTPS
requests behind a TLS-terminating proxy. Add a line after line 476 that sets
SECURE_PROXY_SSL_HEADER to ('HTTP_X_FORWARDED_PROTO', 'https') when
USE_X_FORWARDED_HOST is True, so request.is_secure() returns True and
build_absolute_uri generates https URLs, preventing OAuth redirect mismatches.
2 participants
Description
This PR addresses an issue with the generation of the redirect_url during the Google OAuth flow. Previously, the backend was generating URLs using the internal host (api.domain.internal), which resulted in misconfigured redirect URIs and subsequent OAuth errors.
According to docs this setting should help.
This change makes sure that when the backend receives a /auth/google request, it includes the X-Forwarded-Host header containing the proper web host (e.g., mydomain.com). As a result, the generated redirect_url now aligns with the expected domain provided by GodMod, avoiding any discrepancies and OAuth errors.
I have also attached screenshots of the OAuth error screens for reference, which illustrate the issues encountered due to the mismatched redirect URIs.
Mismatched google oauth url looks like this:
https://accounts.google.com/o/oauth2/v2/auth?client_id=<client_id>&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile&redirect_uri=https%3A%2F%2Fapi.domain.internal%3A8000%2Fauth%2Fgoogle%2Fcallback%2F&response_type=code&access_type=offline&prompt=consent&state=<some_state>─────────────────────────────
Type of Change
─────────────────────────────
Screenshots and Media (if applicable)
─────────────────────────────
Test Scenarios
─────────────────────────────
References
Summary by CodeRabbit