Files
DriverVault/Phone App/lib/auth.dart
T
tajniak81andClaude Opus 5 12ec10a797 Phone App: more than one server, and a session for each
The web app can be pointed at two DriverVault stacks and switch between them in
a click. The phone had one address and one session: reaching a second garage
meant retyping the API base in Server settings and signing in again, losing the
first server's token on the way — the same act, undone, every time you switched
back.

So lib/servers.dart is the web's servers.js ported rather than reinvented, down
to the storage keys: cc_servers holds the list, cc_active_server the one being
read, cc_session_<id> the token minted by that server and no other. The two apps
describe the same thing the same way, and the upgrade path falls out of it —
cc_token, cc_user and cc_server_url are read once at boot and folded onto the
home entry, so the build carrying this signs nobody out.

Home is the address the build ships with (kDefaultApiBase, still overridable per
device from the login screen) and cannot be removed: it is what a dropped session
falls back to. Any other server is added by address, with /api appended if the
path is left off, because a server a phone can reach is internet-facing already.

The part worth reading twice is which session a rejection ends. ApiClient no
longer holds a base or a token — it pins the active server's id, base and token
at the moment a request goes out, so a 401 arriving after a switch clears the
session of the server that actually refused it rather than whichever one is
active by then. The fallback is the web's: a remote server timing out drops its
own token, the app returns to home while home is still signed in, and only when
nothing is left to fall back to does the login screen come back. Log out still
clears every server at once, since leaving the app means leaving all of them.

Switching rebuilds the shell, keyed on the active id, because record ids belong
to the server that issued them — a garage, a charging page and a settings panel
still holding the other server's rows would each have to be told to forget them
separately. The appearance prefs come across with the profile of whoever owns
the account on the server now active.

Where the picker lives is the one place the phone cannot copy the web. There is
no app rail here, so it became the first button in the Garage header, beside the
theme toggle and log out, which is that same cluster. It names the active server
once there is a choice and goes straight to adding the second when there isn't;
the eyebrow reads GARAGE · Work for the reason the rail names it — two garages
otherwise look identical. The login screen gets its own way in, because a remote
session can expire and land you there with that server still active, and a
picker reachable only from inside the app would leave nowhere to go.

One judgment call inside the sheet: saving a connected server at a new address
saves and stops, rather than falling through to the sign-in it now needs. The
token was minted by the PocketBase behind the old address and is dropped with
it, but the credentials to replace it were never asked for, so treating the save
as a login would report an empty password as the error.

The strings are copied out of Web App/web/src/i18n/ like the rest of the shared
wording. Two are not the web's: home reads "the address this app ships with"
rather than "served with this app", since the phone has no origin to be served
from, and sameOrigin has no meaning here at all and was dropped.

Biometric sign-in stays global. It was never per-server and replays its stored
credentials against whichever server is active; making it per-server is a change
of its own, and the login screen now names the server it is about to sign into.

Nothing changes on the API Server. On Android there is no origin to allow, so
the CORS list the web app has to satisfy to reach a second server doesn't enter
into it.

Verified: flutter analyze is clean and flutter test passes, 35 tests to 46. The
new ones cover the registry — a bare origin gaining its /api, a fresh install
knowing one unnamed server on the built-in address, the legacy keys landing on
home and being cleared, two servers holding their tokens apart, a rename keeping
a session where a move drops it, removing the active server falling back to a
home that is still signed in, home refusing to be removed, and a restart reading
the list, the active id and every session back.

Not verified: none of it has been run. There is no device or emulator on this
machine and no API Server to answer, so the picker, the add sheet, a real
connect, the 401 fallback and the shell rebuild on a switch exist only as code
the analyzer is happy with — the tests reach the registry, not a screen. No APK
was built. The legacy migration was exercised against mocked SharedPreferences,
which is not a phone that had the old build on it: that is the first thing to
check on a device, since the failure mode is a silent sign-out.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 21:47:01 +02:00

127 lines
4.8 KiB
Dart

import "package:flutter/foundation.dart";
import "api.dart";
import "i18n.dart";
import "models.dart";
import "servers.dart";
/// Session state for whichever server is active. The tokens themselves are held
/// per server by [serverRegistry] — each one is a separate PocketBase, so a
/// session cannot be shared — and this service mirrors the active one, so every
/// screen goes on reading `authService.user` without knowing that more than one
/// server exists.
class AuthService extends ChangeNotifier {
final ApiClient api;
bool ready = false;
/// In-memory (never persisted) app-lock flag. When biometric login is enabled
/// the app starts/returns locked: the token is still valid but the UI hides
/// behind a biometric unlock instead of jumping straight to the dashboard.
bool locked = false;
AuthService(this.api) {
api.onUnauthorized = _onUnauthorized;
// Switching servers swaps the whole session: a different PocketBase, a
// different user record. Everything watching this service rebuilds on it.
serverRegistry.addListener(notifyListeners);
}
/// The user of the active server's session, or null when it has none.
AuthUser? get user => serverRegistry.activeSession?.user;
bool get isAuthenticated => serverRegistry.activeToken != null;
void lock() {
if (!locked && isAuthenticated) {
locked = true;
notifyListeners();
}
}
void unlock() {
if (locked) {
locked = false;
notifyListeners();
}
}
/// Sessions are read by [ServerRegistry.load]; this only flips the flag that
/// tells the app boot is done.
Future<void> loadFromStorage() async {
ready = true;
notifyListeners();
}
/// Logs into one server and makes it active. The login screen calls it for
/// whichever server is active; the server sheet calls it for one that isn't
/// yet, which is why the credentials are checked against that server's own
/// base before anything switches.
Future<void> connect(String serverId, String email, String password) async {
final server = serverRegistry.byId(serverId);
if (server == null) throw ApiException(404, t("servers.unknown"));
final (token, u) = await api.loginAt(serverRegistry.baseFor(server), email, password);
locked = false;
serverRegistry.setSession(serverId, token, u);
serverRegistry.setActive(serverId);
notifyListeners();
}
Future<void> login(String email, String password) =>
connect(serverRegistry.activeId, email, password);
/// Signs out of one server without leaving the app — the server sheet's own
/// action. Dropping the active one falls back to home, the same way an expired
/// token does.
void disconnect(String serverId) {
serverRegistry.clearSession(serverId);
if (serverRegistry.activeId == serverId && serverId != kHomeServerId) {
serverRegistry.setActive(kHomeServerId);
}
notifyListeners();
}
/// Replaces the cached user of the active server's session — the settings
/// screen renaming the account, say. The token it was minted with stands.
void adoptUser(AuthUser updated) {
final session = serverRegistry.activeSession;
if (session == null) return;
serverRegistry.setSession(serverRegistry.activeId, session.token, updated);
notifyListeners();
}
/// Adopts the role from a freshly fetched profile. A session's role can change
/// under it — creating an organization promotes the creator to that org's admin
/// — and the nav gates the Users tab on the cached copy, so it has to catch up
/// without requiring a re-login. A no-op when the role is unchanged.
Future<void> adoptRole(UserProfile profile) async {
final u = user;
if (u == null || profile.role == u.role) return;
adoptUser(AuthUser(id: u.id, email: u.email, name: u.name, role: profile.role));
}
/// Signs out everywhere. Leaving the app means leaving every server you
/// reached from it — a live token left behind on a shared phone would be worse
/// than the inconvenience of logging back in.
Future<void> logout() async {
locked = false;
serverRegistry.clearAllSessions();
serverRegistry.setActive(kHomeServerId);
notifyListeners();
}
/// A server rejected the token it was given. Only that server's session ends:
/// a remote one timing out shouldn't tip you out of the app, so fall back to
/// home while it is still connected, and land on the login screen only when
/// there is nothing left to fall back to.
void _onUnauthorized(String serverId) {
serverRegistry.clearSession(serverId);
if (serverRegistry.activeId == serverId &&
serverId != kHomeServerId &&
serverRegistry.isConnected(kHomeServerId)) {
serverRegistry.setActive(kHomeServerId);
}
if (!isAuthenticated) locked = false;
notifyListeners();
}
}