Public Access
Stay signed in, come back online by itself, and let a machine be given up
Three things a machine that has been set up could not do. Unlock now takes Enter, which is the gesture everybody makes after typing a password and which did nothing until they found the button. Signing in survives a relaunch. The refresh token is kept in the local cache, sealed under the vault's own cache key, so a later launch resumes the session through the refresh grant with no browser and nobody present — and because it is sealed under that key, only an unlocked vault can resume it. A locked client therefore cannot reach the server at all, which is a consequence worth stating rather than working around; docs/crypto.md §3.2 records it. Every sync pass asks the shell for a connection rather than reading one captured at unlock, so a laptop that unlocked on a train is online within a minute of finding a network, with nothing pressed. Unlocking itself still never waits on a socket. Signing out empties this machine: the profile, the cached items, the outbox and this machine's device key, with the account's row withdrawn when the server can be reached. It asks first and says what it costs — the outbox count when the vault is open, an admission that it cannot be counted when it is not, and the shells that keep running either way. The vault is on the server and is untouched, which is what makes the same button the only honest answer to a forgotten passphrase, so it is on the unlock screen as well as in preferences. It cannot end the session at the identity provider, and says so. Two defects surfaced on the way. The synchronisation pass that runs when the vault opens never ran at all: the loop is started from inside the unlock command, so the busy flag it yields to was raised by that command — the first sync was a minute late on every launch. And signing in from preferences while unlocked threw an unlock screen over an open vault whose keys were still in memory. The unlock card and the new confirmation live in their own controls because MainWindow cannot be laid out headless, so markup left inside it is markup no test can measure; both are now measured at the window's minimum size in the shapes that grow. What is still unverified is the composed window itself.
This commit is contained in:
@@ -73,6 +73,7 @@ public sealed class ClientCacheContext(DbContextOptions<ClientCacheContext> opti
|
||||
ArgumentNullException.ThrowIfNull(modelBuilder);
|
||||
|
||||
ConfigureUnlockMaterial(modelBuilder);
|
||||
ConfigureRememberedSignIn(modelBuilder);
|
||||
ConfigureVaults(modelBuilder);
|
||||
ConfigureItems(modelBuilder);
|
||||
ConfigureOutbox(modelBuilder);
|
||||
@@ -102,6 +103,26 @@ public sealed class ClientCacheContext(DbContextOptions<ClientCacheContext> opti
|
||||
entity.Property(row => row.KdfSalt).IsRequired();
|
||||
});
|
||||
|
||||
/// <remarks>
|
||||
/// A table of its own rather than two more columns on <c>unlock_material</c>, because the two rows have
|
||||
/// opposite lifetimes: the unlock material is what makes this machine work offline and must survive
|
||||
/// everything short of a reset, while a remembered sign-in is dropped the moment the server stops
|
||||
/// accepting it. Deleting one must never be able to take the other with it.
|
||||
/// </remarks>
|
||||
private static void ConfigureRememberedSignIn(ModelBuilder modelBuilder) =>
|
||||
modelBuilder.Entity<RememberedSignInRow>(entity =>
|
||||
{
|
||||
entity.ToTable(
|
||||
"remembered_sign_in",
|
||||
table => table.HasCheckConstraint(
|
||||
"ck_remembered_sign_in_singleton",
|
||||
$"id = {RememberedSignInRow.SingletonId}"));
|
||||
|
||||
entity.HasKey(row => row.Id);
|
||||
entity.Property(row => row.Id).ValueGeneratedNever();
|
||||
entity.Property(row => row.SealedRefreshToken).IsRequired();
|
||||
});
|
||||
|
||||
private static void ConfigureVaults(ModelBuilder modelBuilder) =>
|
||||
modelBuilder.Entity<CachedVaultRow>(entity =>
|
||||
{
|
||||
|
||||
Reference in New Issue
Block a user