Skip to content

fix(auth): harden macOS Google sign-in, session persistence, and login popup - #41

Open
mihaimetal wants to merge 5 commits into
NUber-dev:mainfrom
mihaimetal:fix/macos-auth
Open

fix(auth): harden macOS Google sign-in, session persistence, and login popup#41
mihaimetal wants to merge 5 commits into
NUber-dev:mainfrom
mihaimetal:fix/macos-auth

Conversation

@mihaimetal

@mihaimetal mihaimetal commented Jul 16, 2026

Copy link
Copy Markdown

Summary

  • Harden macOS Google sign-in/out: per-account WebKit data stores, wipe residual HTTPStorages on sign-out, hand off via www.youtube.com, don’t interrupt 2FA.
  • Keep sessions alive with a stable WK data store + short-lived session-keeper refresh (then tear down the keeper).
  • Stop ad-hoc rebuilds from “logging you out”: cookie AES key is file-backed in Application Support only — no Keychain / no permission prompts.
  • Login popup: fail broken Google passkey/hybrid Bluetooth UI early and guide users to password / “Try another way” (Apple only allows real passkeys for browser-entitled apps).

Context

WKWebView does not isolate Google sessions the way WebView2 data_directory does. Extracted cookies also die without a real browser refresh. Separately, Keychain-bound encryption keys break across ad-hoc code signatures, which made every local rebuild look signed out and left successful Google logins stuck in the popup only. Passkeys for google.com cannot work in an embedded WebView without Apple’s browser-only entitlement.

Test plan

  • Sign in with Google on macOS using password (or Try another way) — popup should close and main app show the account
  • Quit and relaunch the same build — still signed in
  • Rebuild the app ad-hoc and relaunch — still signed in, no Keychain prompt
  • Sign out — next sign-in should not auto-use the previous Google session
  • Multi-account switch if applicable
  • Confirm Windows path unchanged (DPAPI cookies)

@mihaimetal

Copy link
Copy Markdown
Author

Rebased onto current main after 0.4.0 so this is a clean merge candidate against the release tree.

@mihaimetal mihaimetal changed the title fix(auth): harden macOS Google sign-in and sign-out fix(auth): harden macOS Google sign-in, session persistence, and login popup Jul 27, 2026
…n popup

Rebased on 0.4.2 (preserves upstream atomic jar writes, power-resume
refresh, and auth-presence UI):

- Per-account WKWebsiteDataStore ids (transferable on re-login dedup)
- Wipe residual HTTPStorages on sign-out; hand off via www.youtube.com
- Seed cold keepers from cookies.enc; destroy keeper after each refresh
- File-backed AES key (no Keychain prompts on ad-hoc rebuilds)
- Fail WebAuthn early in the login popup so Google offers password path
- Last-account sign-out is a full wipe from the sidebar
Prefer the file-backed AES key so ad-hoc rebuilds stay signed in. When
an older Keychain key still exists and disagrees with a stale file key,
prefer Keychain and re-migrate it into Application Support.
Reading or writing the system keyring after an ad-hoc macOS rebuild
pops the Keychain ACL dialog and can swap in a different AES key than
the app-data file, stranding the session between builds.

Make the file key the only steady-state source: consult Keyring only
when the file is missing (one-time upgrade migrate), never write
Keychain items, and never fall back to Keychain when a file key is
already present.
… key

Some installs still have an experimental app-data file key that cannot
open a jar sealed by the older pure-Keychain path. Trying Keychain on
every launch re-prompts after each ad-hoc rebuild; never trying it
strands the session forever.

Keep the file key as the only steady-state source, but if that key
fails to open the jar, consult Keychain once (marker file prevents
repeat prompts), and on success replace the file key so later rebuilds
stay silent and signed in.
Remove the keyring crate and every Keychain/Secret Service code path.
Cookie jars are AES-GCM sealed with a 32-byte key stored only under
Application Support (mode 0600). Ad-hoc macOS rebuilds no longer trigger
ACL permission dialogs, and the session key is stable across rebuilds.

Jars previously sealed only under Keychain cannot be opened without that
key; sign in once after upgrading so the jar is re-sealed with the file
key.
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.

1 participant