GitHub sign-in fails when the OAuth App has more than one redirect URI

オープン
#643 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
55/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
github, rust

調査の方向性

Read login_handler and callback_response in src/web/auth.rs, then trace how the OAuth redirect URI and state cookie are built and validated. Reproduce the flow with two registered callback URIs and compare the callback address with the sign-in origin. Done when sign-in returns to the originating address and the callback accepts its state.

索引モデルが issue の本文から書いたものです。

説明

Observed behavior

GitHub sign-in fails with {"error":"Login state is missing or expired."} when the server is reached at an address other than the first redirect URI registered on the OAuth App. With http://127.0.0.1:3000/api/callback registered first and a tunnel's https://<name>.trycloudflare.com/api/callback added second, signing in from the tunnel address failed this way. Signing in from the tunnel worked once the tunnel's callback was the only redirect URI on the app.

Expected behavior

Signing in returns to the address the sign-in started from, as long as that address's callback is registered on the OAuth App.

Reproduction
  1. Register a GitHub OAuth App with two redirect URIs, http://127.0.0.1:3000/api/callback first and a second origin's /api/callback after it. GitHub's OAuth App settings now accept up to ten.
  2. Set GITHUB_CLIENT_ID, GITHUB_CLIENT_SECRET and SESSION_SECRET, run cargo run -- web, and expose port 3000 on the second origin (I used cloudflared tunnel --url http://127.0.0.1:3000).
  3. Open /peer-lobby on the second origin and press Sign in with GitHub, then Authorize.
  4. The page shows {"error":"Login state is missing or expired."}.
CodeTrial version

codetrial 0.1.0 (5e00eab), built from source on Windows 11. The working tree had uncommitted changes in desktop/, src/config.rs, src/launch.rs and src/web/setup_edit.rs, none of them in the sign-in path.

Initial analysis
  • Path: login_handler in src/web/auth.rs:127 (at 5e00eab) builds the authorize URL as {oauth_base}/login/oauth/authorize?client_id=...&state=...&scope=... with no redirect_uri. The state cookie it sets belongs to the origin the request came in on.
  • Evidence: the authorize URL in the browser carried only client_id, state and scope. Without redirect_uri, GitHub redirects to the app's default callback, which for an app with several redirect URIs is the first one. callback_response (src/web/auth.rs:292) then runs on 127.0.0.1, which never received the state cookie, and returns the 401 above.
  • Hypothesis: the redirect landed on http://127.0.0.1:3000/api/callback. I did not capture the address bar after the failure; repeating step 3 and reading it would confirm or refute this.

Two directions, not yet compared against the code: send redirect_uri built from the request's origin, which needs the Host the server already accepts through CODETRIAL_ALLOWED_HOSTS and the proxy settings; or keep the single-callback design and say in the docs and in the error that the app must have exactly one redirect URI, for the origin users sign in from.

Sanitized evidence
{"error":"Login state is missing or expired."}
  • I removed credentials, session tokens, candidate recordings, and personal interview content from this public report.
主要言語
Rust
スター
228
フォーク
150
平均マージ
1日 3時間
マージ済み PR(30日)
230

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

sysprog21/codetrial のほかの issue

sysprog21/codetrial の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。