Skip to content

Add an OAuth client for the FAF Rust Client - #335

Merged
Sheikah45 merged 1 commit into
FAForever:developfrom
TimMasalme:feat/rust-client-oauth
Oct 6, 2026
Merged

Sheikah45 merged 1 commit into
FAForever:developfrom
TimMasalme:feat/rust-client-oauth

Conversation

@TimMasalme

Copy link
Copy Markdown
Contributor

The FAF Rust Client has been signing in with the Python client's OAuth client (95ecec08-…). This gives it its own.

The entry is a copy of "FAF Classic Client (Python)", field for field. The Rust client already requests exactly those scopes and uses the same loopback redirect (http://127.0.0.1:<ephemeral port>, RFC 8252), so only the name and the id differ:

  • id 03c2132b-b5f8-4cbd-9901-499e83700f45 (a fresh random UUID)
  • public PKCE client, tokenEndpointAuthMethod: "none", no secret

Order of rollout:

  1. This lands on test, then prod.
  2. Only once it is live on prod does the client switch its default id, in its next release.
  3. The Python entry stays as it is: released Rust clients keep using it until they update.

Checked with helm template apps/ory-hydra against config/prod.yaml: the new client shows up in the client-creation job like the others.

The Rust client has been signing in with the Python client's id. Give it
its own entry, copied field for field from the Python one (same scopes,
the same loopback redirects, public PKCE client); only the name and the
id differ. The Python entry stays: released Rust clients keep using it
until they update.
@coderabbitai

coderabbitai Bot commented Oct 6, 2026

Copy link
Copy Markdown

Important

  • 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration
  • Configuration used: defaults
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: de25bf19-faca-4451-86c4-9d1547f3d965
  • Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@Sheikah45
Sheikah45 merged commit c3c86e1 into FAForever:develop Oct 6, 2026
2 checks passed
Sheikah45 pushed a commit that referenced this pull request Oct 6, 2026
The Rust client has been signing in with the Python client's id. Give it
its own entry, copied field for field from the Python one (same scopes,
the same loopback redirects, public PKCE client); only the name and the
id differ. The Python entry stays: released Rust clients keep using it
until they update.
TimMasalme added a commit to FAForeverRustClient/FAForeverRustClient that referenced this pull request Oct 7, 2026
FAForever/gitops-stack#335 registered "FAF Rust Client" with Hydra
(03c2132b-b5f8-4cbd-9901-499e83700f45), so the client no longer has to
borrow the Python client's id, and FAF retiring that client no longer
locks every user out.

Hydra binds a refresh token to the client that obtained it and refuses
to renew it under any other id. Swapping the id alone would therefore
have signed out every user who ticked "Remember me" on the first launch
of the update. The keyring entry now records the issuing client next to
the token, and both the restore and the background renewal use that
client. A bare token from before this change is read as the Python
client's, keeps renewing under it, and the user moves to the new id at
their next interactive login.

(cherry picked from commit 0aaafda)
NoryGit pushed a commit to NoryGit/FAForever-Rust-Client that referenced this pull request Oct 8, 2026
FAForever/gitops-stack#335 registered "FAF Rust Client" with Hydra
(03c2132b-b5f8-4cbd-9901-499e83700f45), so the client no longer has to
borrow the Python client's id, and FAF retiring that client no longer
locks every user out.

Hydra binds a refresh token to the client that obtained it and refuses
to renew it under any other id. Swapping the id alone would therefore
have signed out every user who ticked "Remember me" on the first launch
of the update. The keyring entry now records the issuing client next to
the token, and both the restore and the background renewal use that
client. A bare token from before this change is read as the Python
client's, keeps renewing under it, and the user moves to the new id at
their next interactive login.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants