Skip to content

πŸ› fix(auth): stop entering a session for a server that was never logged into - #50

Merged
hub2rock merged 2 commits into
mainfrom
fix/first-server-skips-login
Aug 20, 2026
Merged

πŸ› fix(auth): stop entering a session for a server that was never logged into#50
hub2rock merged 2 commits into
mainfrom
fix/first-server-skips-login

Conversation

@hub2rock

Copy link
Copy Markdown
Contributor

Reported from the first TestFlight build: adding the very first server lands on the projects list without ever asking for credentials.

Cause

activeProfile stands for an authenticated session β€” RootView presents MainView as a full-screen cover the moment it turns non-nil. Two places set it with no token stored.

addProfile activated the profile whenever it was the first one. AddServerView does push the login screen right after, but the cover goes up first and buries it β€” which is why only the first server showed the bug; a second one logs in normally. selectServer already carries the guard against precisely this ("Selecting must not activate a profile with no token, or the app would drop into a session it can't authenticate"); it was simply missing here. Both login paths call setActiveProfile on success, so activating on add was redundant as well as harmful.

loadFromUserDefaults fell back to profiles.first when no active profile was stored. That brings the same bug back one relaunch later β€” and it quietly undid logging out. Logout and "switch server" both remove the stored key on purpose, so the next launch walked straight back into the session the user had just left; after a logout, with no token at all.

Fix

Activation now happens only where a token has been stored, and only an explicitly saved profile is restored on launch.

Tests

159 passing (2 new). Four existing tests encoded the old behaviour and now activate explicitly, the way the login flow does:

  • addProfile appends without activating, even for the first profile β€” inverted
  • profiles persist across instances β€” a saved-but-never-logged-into server no longer resumes a session
  • an authenticated profile is restored on relaunch β€” new, guards the legitimate case
  • clearing the active profile survives a relaunch β€” new, covers the logout regression

swiftformat --lint clean on both files. Note the repo is formatted with 0.61.1 (as CI pins) while 0.62.1 locally flags ~37 pre-existing files β€” unrelated drift, untouched here.

πŸ€– Generated with Claude Code

hub2rock and others added 2 commits August 20, 2026 18:09
…ed into

Adding the very first server dropped straight onto the projects list without
ever asking for credentials.

`activeProfile` stands for an authenticated session β€” `RootView` presents
`MainView` as a full-screen cover the moment it turns non-nil. Two paths set it
without a token ever being stored:

- `addProfile` activated the profile whenever it was the first one, so the login
  screen `AddServerView` pushed right after was covered before it could be seen.
  `selectServer` already guarded against exactly this ("must not activate a
  profile with no token"); the guard was simply missing here. Both login paths
  call `setActiveProfile` on success, so activation on add was redundant too.
- `loadFromUserDefaults` fell back to `profiles.first` when no active profile was
  stored. That resurrected the same bug one relaunch later, and it also undid
  logging out: logout and "switch server" deliberately remove the stored key, so
  the next launch walked straight back into the session the user had just left β€”
  with no token at all in the logout case.

Activation now happens only where a token has been stored, and only an explicitly
saved profile is restored.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@hub2rock
hub2rock merged commit cc61c0e into main Aug 20, 2026
6 checks passed
@hub2rock
hub2rock deleted the fix/first-server-skips-login branch August 20, 2026 16:16
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