session/security: IAuthorizer::authorize also gates 'instances' and 'schemas' with an empty actionType, but is documented as execute-only

[Yaraslaut]

Summary

IAuthorizer::authorize's doc says it is "Called once per execute envelope". RemoteServer also calls it on instances and schemas, passing an empty actionType. An authorizer written as an allowlist over actionType — the shape the parameter doc invites — therefore evaluates against "" on the two disclosure channels.

Verification status

Verified by reading the call sites. Not exercised against a real IAuthorizer implementation; I have not shown a concrete policy failing open.

grep -n "_authorizer->authorize" include/morph/core/remote.hpp:

1192:  if (!_authorizer->authorize(env.session, env.typeId, {})) {     <- instances
1209:  if (!_authorizer->authorize(env.session, env.typeId, {})) {     <- schemas
1317:  if (!_authorizer->authorize(env.session, env.modelType, env.actionType)) {   <- execute

The server side is deliberate and says so (remote.hpp:1188-1191, :1201-1207: "gate it with authorize for the model type (empty action id)"). The interface doc is the stale side.

Why it matters more than a wording nit

session.hpp:111 documents @param actionType as "String id of the action being invoked", with no note that it can be empty. An implementation that switches or matches on actionType will hit its default arm for instances and schemas — and schemas returns, per remote.hpp:1204-1206, "field names, bounds, rules and the payload fingerprint of every action". Whether that fails open or closed depends entirely on how the embedder wrote the default, and nothing in the contract tells them the case exists.

SigningAuthorizer::Policy (session_auth.hpp:521-526) has the same gap: its doc says only "the target ids".

docs/spec/session/session.md:416 repeats the stale claim ("Called per execute envelope"), so header and spec agree with each other and disagree with the code.

What would change the verdict

• Close it by correcting the three doc sites — that is very likely the whole fix; the server behaviour looks correct and intentional.
• Raise it if any shipped or example authorizer is shown to fail open on the empty actionType.

Adjacent, same file

SigningAuthorizer runs a full token verification twice per request — authorize() (session_auth.hpp:572) and authenticate() (:583) each call _verifier.verify(ctx.token, _clock()). That is two base64url decodes, two HMAC-SHA256 passes and two Glaze parses per authenticated request, from two separate clock samples. remote.hpp:1323-1330 documents the resulting expiry window; none of the three doc blocks in session_auth.hpp mention that verification is repeated or that the two calls can disagree. Also session_auth.hpp:470 builds std::string{payload} for a string_view parameter, allocating on every verification — so twice per request.

[Yaraslaut]

Triage: triage: rescope, area: session — and removing bug

Correcting my own filing. I labelled this bug. That is wrong by this repository's own rule: "Add bug only for a defect in shipped behaviour — not for a spec/code disagreement (that is triage: rescope plus the area)." Nothing here is a defect in shipped behaviour.

Premise re-checked, and the code is right. grep -n "_authorizer->authorize" include/morph/core/remote.hpp gives :1192 (instances), :1209 (schemas) and :1317 (execute). The first two pass {} as actionType — and both are deliberate, with the reasoning already in the source:

:1188-1191 — "Enumeration is a read channel over the directory: gate it with authorize for the model type (empty action id) so a deployer can refuse listing without refusing use."

:1201-1207 — "It is a real disclosure — field names, bounds, rules and the payload fingerprint of every action — so it must not be reachable by a caller the server would not let execute."

Gating disclosure channels on authorize is the correct behaviour and the comments show it was a decision, not an accident. This is invariant 5's shape exactly: two artefacts disagree, and the code is the one that is right.

So the issue is real but mis-framed. It reads as "the server does something undocumented"; what it actually is, is "IAuthorizer's contract does not describe its own call sites, and an implementor cannot know actionType can be empty." That reframing changes the fix from "investigate the server" to "correct three doc sites and state the empty-actionType case as part of the interface contract":

• session.hpp:96 — "Called once per execute envelope"
• session.hpp:111 — @param actionType "String id of the action being invoked", with no empty case
• docs/spec/session/session.md:416 — same stale claim
• session_auth.hpp:521-526 — SigningAuthorizer::Policy, same gap

What keeps it security-relevant rather than cosmetic: an authorizer written as an allowlist over actionType hits its default arm on the two disclosure verbs, and whether that fails open or closed is entirely the embedder's, decided without being told the case exists.

What would raise it back to bug: a shipped or example authorizer shown to fail open on the empty actionType. I did not find one; I also did not audit the rungs' authorizers exhaustively.

Not folding in: the double-verification and the needless std::string{payload} allocation noted at the bottom of the issue are a separate performance concern in SigningAuthorizer. If they are worked, they should be split out.