ledger rung 5 has no auth story: the shipped GUI installs no principal, and RemoteServer would clear one anyway

[Yaraslaut]

What I found

Rung 5 (examples/ledger) has no authentication or authorization story at all, and the consequence is that every mutating LedgerModel/BudgetModel/RuleModel action fails in the shipped desktop client, in both deployment modes.

Every mutating action in the rung opens with the same gate:

const auto* ctx = morph::session::current();
if (ctx == nullptr || ctx->principal.empty()) {
    throw EmptyPrincipalError{};
}

There are two independent ways rung 5 fails to supply that principal.

1. Local mode: nobody ever installs one

examples/ledger/gui/main.cpp builds an AppContext and four QML bridges, and never calls ctx.login(...). Nothing in examples/ledger/gui_lib/ calls Bridge::setDefaultSession either:

$ grep -rn "login\|setDefaultSession\|principal" examples/ledger/gui_lib/ examples/ledger/gui/main.cpp
examples/ledger/gui/main.cpp:65:        // Nothing is torn down and rebuilt around login: a login only installs

AppContext's default session is empty, so LocalBackend installs an empty session::Context and OpenAccount — the first thing a user does — throws EmptyPrincipalError.

Contrast bookmarks/kanban, whose gui/main.cpp files each mint a Local-mode token and log in explicitly.

2. Remote mode: RemoteServer clears the claim, and there is no server anyway

RemoteServer::dispatchExecute (include/morph/core/remote.hpp) does:

if (auto verified = _authorizer->authenticate(env.session)) {
    env.session.principal = std::move(*verified);
} else {
    env.session.principal.clear();
}

which is correct and deliberate (docs/spec/security.md: never pass an unverified claim through). But IAuthorizer::authenticate's default — and therefore AllowAllAuthorizer's — returns nullopt, so with the allow-all default any principal is cleared. Rung 5 ships no src/auth/, no AuthModel, no Login action and no token secret, so allow-all is the only authorizer it can install.

It also ships no src/server/, so there is no ladder_ledger_server for --server <url> to connect to.

Verification status

Inferred from reading the code, not reproduced by running the GUI. What I did measure, on fix/160-ledger-app-layer (branched from d6690c5): an App dispatching RunReportJob over a RemoteServer with the allow-all default failed with the model's own principal check, which is the same mechanism:

[ERROR] [ledger::App] RunReportJob dispatch failed for job 1: RunReportJob: only the report runner may run a report job

Switching that dispatch to a LocalBackend (which installs the session directly, with no authenticate step) made it pass. That is direct evidence for (2). For (1) I have only the greps above and the gate's source; I did not launch ladder_ledger_gui.

Note that examples/ledger/tests/test_multiclient.cpp uses BackendRig in Mode::Local, so rung 5's own suite has never exercised a RemoteServer carrying a principal — which is why this has stayed invisible.

What would change the verdict

Close this if either turns out to be wrong:

• launching ladder_ledger_gui and successfully creating an account (would falsify (1));
• a session path I missed that installs a principal for the rung's bridges.

Otherwise this closes when rung 5 gains a login + authorizer (and, if it is to have a Remote mode at all, a src/server/main.cpp), the way rungs 1-4 each did.

Not folded into #160

Found while implementing #160 (moving the report job out of LedgerModel into an App layer). Per AGENTS.md it is filed rather than fixed there: that PR works around (2) by dispatching over a LocalBackend and says so in examples/ledger/include/ledger/app/app.hpp, and does not touch (1) at all.

[Yaraslaut]

Triage: triage: valid

Both premises verified independently — one read-verified, one execution-verified, plus a second, independent real-world hit of the same root cause found while triaging this issue.

(1) Local mode: nobody ever installs a principal — read-verified

examples/ledger/gui/main.cpp builds AppContext and the four QML bridges inside ctx.onReady() and never calls ctx.login(...). Confirmed by grep — no hit anywhere in the rung's GUI shell or gui_lib/:

$ grep -rn "login\|setDefaultSession\|principal" examples/ledger/gui_lib/ examples/ledger/gui/main.cpp
examples/ledger/gui/main.cpp:65:        // Nothing is torn down and rebuilt around login: a login only installs

AppContext::login() (examples/common/gui/app_context.cpp) exists and does exactly what's needed:

void AppContext::login(const std::string& principal) {
    _bridge->setDefaultSession(::morph::session::Context{.principal = principal});
}

but is never called by ledger. Contrast confirmed directly: examples/bookmarks/gui/main.cpp and examples/kanban/gui/main.cpp both wire a real login path before any handler is used (kanban's ProjectAdminPresenter::login() dispatches a Login action and calls _bridge.setDefaultSession(session) on success). Ledger has no analogous presenter, action, or call anywhere.

Bridge::_defaultSession (include/morph/core/bridge.hpp) is a default-constructed session::Context member — empty principal unless setDefaultSession is called. So every LocalBackend-dispatched call in the shipped ladder_ledger_gui carries an empty principal.

(2) Remote mode: RemoteServer clears the claim, and there is no server — read-verified, and independently execution-hit

RemoteServer::dispatchExecute (include/morph/core/remote.hpp):

if (auto verified = _authorizer->authenticate(env.session)) {
    env.session.principal = std::move(*verified);
} else {
    env.session.principal.clear();
}

This is deliberate per docs/spec/security.md ("The principal is never passed through unverified"). IAuthorizer::authenticate's default returns std::nullopt (include/morph/session/session.hpp); AllowAllAuthorizer does not override it; RemoteServer's no-authorizer constructor falls back to allowAllAuthorizer(). So with the only authorizer rung 5 can install, every principal is cleared. Confirmed: examples/ledger/{src,include} has no auth/ or server/ directory at all — 3 of the 4 comparable rungs (bookmarks, kanban, polls) have both; bank (rung 1, single-user, oldest/simplest) is the only other rung without them.

Independent corroboration: PR #243 (fix/160-ledger-app-layer, same author, open, unrelated to this issue's filing) hit this exact mechanism as a real runtime failure while giving rung 5 an App layer for #160:

[ERROR] [ledger::App] RunReportJob dispatch failed for job 1: RunReportJob: only the report runner may run a report job

and its own PR description independently states: "Rung 5 ships no src/auth/, no AuthModel, no token secret. So a RemoteServer-based App is not merely unauthenticated here; it is one on which no action can carry a principal, and every mutating LedgerModel action refuses an empty one." — same root cause, found the same way (hit at runtime), from a different call path (App-layer dispatch, not the GUI).

Execution-verified: the gate itself

Built binary build/clangcl-release/target/ladder_ledger_tests.exe already covers the gate condition (test_ledger_model.cpp:202, "StoreTransaction refuses an empty principal") — ran it directly against the default SQLite fixture:

StoreTransaction refuses an empty principal
D:\repo\morph\examples\ledger\tests\test_ledger_model.cpp(215): PASSED:
  CHECK_THROWS_AS( model.execute(ledger::StoreTransaction{...}), ledger::EmptyPrincipalError )

i.e. an empty-principal session::Context — exactly what an un-logged-in AppContext/allow-all RemoteServer produces — throws on the model's own gate. OpenAccount (examples/ledger/src/models/ledger_model.cpp:474-478, "the first thing a user does" per the issue) opens with the identical check. examples/ledger/tests/test_multiclient.cpp sidesteps this entirely by manually calling rig.bridge(i).setDefaultSession(ctx) with ctx.principal = "alice" for every client before dispatching anything — which is exactly the step the shipped main.cpp never performs, and exactly why the rung's own test suite has never caught this.

Verdict reasoning

This is not a spec/code disagreement (invariant 5) — no spec mandates every ladder rung ship a login story, and AppContext::login()/Bridge::setDefaultSession() already exist as the correct primitives; ledger's main.cpp simply never calls them. It is not wrong-layer — nothing here asks the framework for something it forbids; the fix is to use existing seams the way three sibling rungs already do. Not invalid — both premises hold, doubly confirmed (read + execution, plus an independent real-world hit from unrelated work). Not unverified — the highest-value experiment (running the exact empty-principal gate) was performed and matches the predicted throw.

Considered triage: parked given examples/FINDINGS.md's "feature completeness is explicitly not an exit criterion; a rung may exit half-built" and examples/LADDER.md's "rungs 5-8 are a design annex" framing — but neither applies here: ledger has not exited (no exit-criteria issue found; area: ladder currently carries a dozen-plus open, actively-triaged bug/enhancement findings against it, e.g. #160, #239, #250, all triage: valid), and the rung's own README lists "Sessions / authorization" (with "empty-principal refusal" named explicitly) as an in-scope cross-cutting concern this rung is meant to exercise — the model half of that is built and tested; only the deployment/GUI half (login + authorizer) is missing. There is no explicit re-entry condition on record deferring this, which parked requires — it reads as an oversight in an actively-worked rung, not a deliberate deferral.

No duplicate found (gh issue list --search "ledger auth" / "principal ledger" / "EmptyPrincipalError" all return only #242 itself). docs/findings/003 covers a different, narrower question (whether a model needs its own background-job seam) and does not cover this.

Verdict: triage: valid. Fix direction as stated in the issue: give rung 5 a login (a presenter analogous to kanban's ProjectAdminPresenter, or foldable into an existing bridge as bookmarks does) that calls AppContext::login(...) / Bridge::setDefaultSession(...) for Local mode, and — if Remote mode is to work at all — a src/auth/ (AuthModel, Login action, token secret) plus src/server/main.cpp wiring a verifying IAuthorizer, the same shape rungs 2-4 each already have.

Labeling triage: valid (existing area: ladder and bug labels are already correct and left as-is).