routes refuse at the route, and a new home is empty
Three things, from a member sitting on /music with no music capability on a server with no music sidecar: an empty library, and 403s in the console. PERMISSIONS AT THE ROUTE. `canVisit` filtered the dock and nothing else, so the tile was hidden and the route was wide open — typing the path, following an old link or restoring a tab rendered the screen anyway. RouteGate now wraps every screen in one place, inside the error boundary. It does not redirect. Sending someone to `/` erases what they asked for and reads as a bug: they clicked Music and landed on Home. It says why instead, and the URL stays put so a reload after installing the thing just works. And it says which of the two reasons applies, because they need different screens and send the reader to different places. `not-installed` is a fact about the SERVER — the owner gets a link to the app store. `not-granted` is a fact about the ACCOUNT, and only the owner can change it. Presenting either as the other sends you looking in the wrong place. ROUTES FOLLOW THE SIDECAR. Free, once the above exists: `deniedRoutes` already covers "held but its sidecar is not installed", so an uninstalled feature has no tile AND no screen. The dock, the Permissions list and the routes now agree because they read one answer. NO MORE SEEDING. Downloads/Documents/Music/Videos/Pictures are gone from both places that made them — the member's provisioning and, older and worse, `/ls`, which created folders in somebody's home as a side effect of LOOKING at it. A listing that invents its own contents is a listing you cannot trust, and the platform has no standing to choose a person's folder layout. A new home is empty. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
import { chmod, mkdir, readdir, stat } from 'node:fs/promises';
|
||||
import { existsSync } from 'node:fs';
|
||||
import { join } from 'node:path';
|
||||
import { DATA_PATH, HOME_SEED_DIRS, USER_DIRS, toShellUsername } from './data-path';
|
||||
import { DATA_PATH, USER_DIRS, toShellUsername } from './data-path';
|
||||
|
||||
// Real Linux accounts for members, so the surfaces that execute code can run as them.
|
||||
//
|
||||
@@ -250,14 +250,10 @@ export async function ensureOsUser(params: { email: string; username: string | n
|
||||
};
|
||||
}
|
||||
|
||||
// Seeded AS the member, because after the chown above their home is 700 and theirs — the platform cannot
|
||||
// write into it, which is exactly the point. Best-effort: an empty file browser is a cosmetic problem, and
|
||||
// failing the whole account creation over Downloads/ would be absurd.
|
||||
const seed = runAs(osUser, ['mkdir', '-p', ...HOME_SEED_DIRS.map((dir) => join(home, dir))]);
|
||||
if ((await seed.exited) !== 0) {
|
||||
console.warn(`[os-user] could not seed ${osUser}'s home folders: ${await new Response(seed.stderr).text()}`);
|
||||
}
|
||||
|
||||
// A new home is EMPTY, deliberately. This used to create Downloads/Documents/Music/Videos/Pictures — a
|
||||
// habit inherited from the file browser, which did the same lazily for the owner. Nothing needs them:
|
||||
// guessing at somebody's folder layout is a decision the platform has no standing to make, and an empty
|
||||
// home is honest about being new.
|
||||
return { ok: true, osUser, uid: ids.uid, gid: ids.gid, created };
|
||||
}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user