server: fix redirect URL in oauth2-proxy flow

[webconn]

I encountered a problem running SkyPilot API server with oauth2-proxy behind a reverse proxy.

This redirect was sending a client to an internal URL (available behind the reverse proxy but not available from the client) thus breaking the flow.

I'm not sure if it was intentional. I can imagine if root_path should be taken into account somehow (e.g. if the server is deployed to be available with a prefix, like http://example.com/my-skypilot/dashboard) and I couldn't find a solid explanation in FastAPI / Starlette docs. In SkyPilot itself though there is a place where such a redirect is already used:

skypilot/sky/server/server.py

Line 2144 in 8572b31

return fastapi.responses.RedirectResponse(url='/dashboard/')

With my fix it seems to work both behind a reverse proxy and directly.

Tested (run the relevant ones):

• Code formatting: install pre-commit (auto-check on commit) or bash format.sh
• Any manual or new tests for this PR (please specify below)
• All smoke tests: /smoke-test (CI) or pytest tests/test_smoke.py (local)
• Relevant individual tests: /smoke-test -k test_name (CI) or pytest tests/test_smoke.py::test_name (local)
• Backward compatibility: /quicktest-core (CI) or pytest tests/smoke_tests/test_backward_compat.py (local)

[gemini-code-assist]

Summary of Changes

Hello @webconn, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical issue in the oauth2-proxy authentication flow when the SkyPilot API server operates behind a reverse proxy. The previous implementation generated an absolute redirect URL that was not accessible to external clients, breaking the authentication process. By switching to a relative path for the sign-in URL, the change ensures that the redirect functions correctly in both direct and reverse proxy deployments, improving the robustness of the authentication mechanism.

Highlights

• OAuth2-proxy redirect URL fix: Modified the signin_url construction in _authenticate to use a relative path (/oauth2/start?) instead of request.base_url. This prevents redirects to internal URLs when the server is behind a reverse proxy, ensuring the OAuth2 flow works correctly for external clients.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request fixes a bug in the OAuth2 proxy flow where redirects would use an internal URL, causing issues when running behind a reverse proxy. The change correctly uses a root-relative path for the redirect. I've suggested a further improvement to also handle deployments under a subpath, making the solution more robust.

[gemini-code-assist]

This change correctly fixes the issue of redirecting to an internal URL when behind a reverse proxy. However, as you noted in the PR description, using a root-relative path /oauth2/start doesn't handle cases where the application is deployed under a subpath (e.g., http://example.com/my-skypilot/). A redirect to /oauth2/start would incorrectly go to http://example.com/oauth2/start.

A more robust solution is to use request.base_url.path to construct the redirect URL. This will include the root_path if the application is mounted under a subpath, while still being a relative path that avoids the internal host issue.

This change will work correctly in all scenarios:

1. Directly: request.base_url.path is /, URL becomes /oauth2/start.
2. Behind a reverse proxy (no subpath): request.base_url.path is /, URL becomes /oauth2/start.
3. Behind a reverse proxy (with subpath, e.g., /my-skypilot): request.base_url.path is /my-skypilot/, URL becomes /my-skypilot/oauth2/start.

This approach is more robust and addresses the concern you raised about base_path. It could also be applied to the other redirect you pointed out in sky/server/server.py for consistency.

Suggested change

	signin_url = (f'/oauth2/start?'
	f'rd={rd}')
	signin_url = (f'{request.base_url.path}oauth2/start?'
	f'rd={rd}')