-
Notifications
You must be signed in to change notification settings - Fork 221
fix(web): Use AUTH_URL when generating external links #844
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This comment has been minimized.
This comment has been minimized.
|
Caution Review failedThe pull request is closed. WalkthroughBase URL sourcing was changed from runtime request headers (and the removed Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
Code reviewNo issues found. Checked for bugs and CLAUDE.md compliance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/web/src/actions.ts (1)
4-4: 🛠️ Refactor suggestion | 🟠 MajorApply the same fix (use
env.AUTH_URLor similar) to origin derivations at lines 894 and 1586.Both
createInvitesandapproveAccountRequestuseheaders().get('origin')to construct external-facing links (invite links at line 917 and approval email baseUrl at line 1589). These have the same Kubernetes deployment issue as the fix applied at line 4—the origin header can be unreliable when requests are proxied. Line 480 shows the pattern already in use:const baseUrl = env.AUTH_URL;. Apply this same approach to lines 894 and 1586 for consistency and reliability.
🧹 Nitpick comments (2)
packages/web/src/features/search/zoektSearcher.ts (1)
429-435: Potential double-slash ifAUTH_URLends with a trailing slash.If
env.AUTH_URLis configured with a trailing slash (e.g.,https://example.com/) andgetBrowsePathreturns a path starting with/, the resulting URL will contain a double slash. Consider normalizing the URL:♻️ Suggested normalization
- webUrl: `${env.AUTH_URL}${getBrowsePath({ + webUrl: `${env.AUTH_URL.replace(/\/$/, '')}${getBrowsePath({ repoName: repo.name, path: fileName, pathType: 'blob', domain: SINGLE_TENANT_ORG_DOMAIN, revisionName: branchName, })}`,Alternatively, you could create a utility function to handle URL concatenation consistently across all the files modified in this PR.
packages/web/src/app/api/(server)/chat/blocking/route.ts (1)
189-190: Same trailing slash concern applies here.If
env.AUTH_URLends with a trailing slash, the constructedchatUrlwill have a double slash (e.g.,https://example.com//org/chat/...).♻️ Suggested normalization
- const baseUrl = env.AUTH_URL; - const chatUrl = `${baseUrl}/${org.domain}/chat/${chat.id}`; + const baseUrl = env.AUTH_URL.replace(/\/$/, ''); + const chatUrl = `${baseUrl}/${org.domain}/chat/${chat.id}`;
Problem
In Kubernetes deployments, when internal services call Sourcebot APIs, the Host header is set to the internal service DNS name. The old getBaseUrl() function used this header to build URLs returned to users, resulting in inaccessible links.
Solution
Since AUTH_URL is a required environment variable that contains the public-facing URL, we now use it directly instead of inferring the URL from request headers.
Summary by CodeRabbit