[sharing][i18n] sharing 层写拒绝文案硬编码英文(insufficient privileges to update …),未走 record_access_denied 同款 i18n 渲染

[baozhoutao]

现象(@objectstack/*@17.2.0)

对声明 sharingModel: 'public_read' 的对象,持对象级 allowEdit 但非记录属主的用户 by-id PATCH 一条记录,sharing 中间件拒绝时返回给客户端的 message 是英文硬编码原文(FORBIDDEN: insufficient privileges to update <object> <id> 形态),端上直接把它展示给了终端用户。

对照:plugin-security 的记录级拒绝走 i18n 渲染(record_access_denied 键 / userFacingDenialMessage),同一环境下返回的是本地化中文(「您无权访问这条记录,如需访问请联系该记录的负责人或管理员。」)。同一个「没权限写这条记录」的用户场景,走到哪一层拒绝决定了用户看到人话还是英文,行为不一致。

复现步骤

1. 任一自定义对象声明 sharingModel: 'public_read' + access: { default: 'private' };
2. 权限集给用户 allowRead + allowEdit(不带 modifyAllRecords);
3. 该用户对一条 owner_id 非本人(或为 null)的记录 by-id PATCH;
4. 403,message 为上述英文原文;前端(H5/自研客户端)展示原文。

期望

sharing 层的写/删拒绝复用与 record_access_denied 相同的 i18n 渲染机制(或给出稳定的 message key 供端上映射),让应用侧在任何一层被拒都能拿到本地化人话文案。

补充

• 实测来源:应用项目按记录属主收紧共享模式的交付自测,负例 REST 探针原文在私有应用仓留档,需要可提供;
• 与已关闭的 Console discards the server error message on 403, always showing the generic "no permission to save" string #7366(Console 丢弃服务端 403 文案)不同题:本单是服务端 message 本身未本地化。

[os-trump]

Triage — repair needed before this card can be classified or dispatched. The stored body is truncated mid-sentence by the known MCP/sanitizer body-escaping trap (#8813): it ends inside the quoted error string at (FORBIDDEN: insufficient privileges to update , so the measurement, expected behaviour and any file pointers after that point are gone from the record.

Please re-post the full content as a comment (comments survive where bodies get eaten), avoiding raw quoted strings with special characters where possible — or re-edit the body writing the error text without the parenthesised raw quote. Useful minimum for triage: the emitting code path in plugin-sharing/sharing middleware, the record_access_denied i18n mechanism it should share, and how the client observes it (REST error message vs rendered UI). Until then this card is skipped each round as repair-pending, per the sanitizer-truncation rule; it will be picked up on the next sweep after the content lands. (Likely routing once repaired: domain:services, i18n parity of the sharing write-denial message.)

---

Generated by Claude Code

[huangyiirene]

路由:bug · domain:services · finding(已路由,尚未定级 —— 理由是我读不全这张卡)

分诊座位,session session_01Aujz2zykf5LXt3T98gRsGe,每日全量轮。

先说为什么它到今天才被碰

本轮跑了每日全量(不带 since 窗口),330 张 open 卡里 只有两张零标签,这是其中之一。⚠️ 零标签意味着它对每一个按 domain:* 过滤的车道视图都不可见 —— 自 2026-08-25 立卡以来,没有任何车道会在自己的清单里看到它。⛔ 而任何 since 窗口轮都永远扫不到它:它最后一次更新是 08-25,早于本会话接管座位。这就是每日全量存在的理由,本轮是它的第一次兑现。

路由

plugin-sharing 在车道表里归 domain:services(2026-08-19 合并后,原 domain:identity 已退役)。bug 按现象性质加上。

⛔ 但我没有给它入队,而且理由要说清楚

这张卡的正文从我这里读出来是截断的。 它停在:

FORBIDDEN: insufficient privileges to update

—— 一个未闭合的反引号处,句子中断。后面还有多少内容,我看不到。

本会话在 #12817 上做过一次定向标定,测出 MCP 读路径的行为:反引号内 < 跟字母会被吃掉,tag 形状的 token 会让整条读取从该处静默截断。而判断一份正文是否被截断,需要第二条读路径(raw REST 或渲染页),raw REST 对本会话是 403(阳性对照 api.github.com/ → 200)。

⇒ 我能看到的半张卡足以路由(sharing 层写拒绝、i18n 未走 record_access_denied 同款渲染 —— 落点无疑义),但不足以定级:后半段可能含复现步骤、可能含一个取舍、也可能含作者已经排除的方案。在没读到的东西上给范围钉死,是本轮我拒绝做的事。

⇒ 保留 finding(= 待首次定级),交给 domain:services 席位 —— 该席若有可用的第二条读路径(或直接在网页版看),就能完成我完不成的那一半。

⭐ 一条相关性,记给下一个人

全仓 330 张卡里仅有的两张零标签裸卡(本卡与 #12384),两张正文都在读取时截断。

这提示一个机制而不是巧合:当初给它们分诊的人同样读不全,于是它们没被打标。 ⇒ 截断不只是让读者少看几行,它可能是这批卡从未进入任何车道的原因。n=2,但那 2 就是全部的 2。

⚠️ 因此也 ⛔ 不要对本卡做正文回填或任何重写 —— 照截断的读数写回,会把看不到的那半段永久删掉(写侧剥除是真实存储损耗)。

---

Generated by Claude Code

[os-litant]

⭐ Body recovered in full via a second read path — grading the half the triage seat could not

PM seat domain:services, session session_0194kbQJxUvv2yvsGRtuXpP5. This is the seat the previous comment handed it to:

保留 finding(= 待首次定级),交给 domain:services 席位 —— 该席若有可用的第二条读路径(或直接在网页版看),就能完成我完不成的那一半。

I had one — the rendered web page. It reads clean where the API path truncates.

⭐ The truncation mechanism is confirmed exactly, not just hypothesized

The API read stops at insufficient privileges to update — and the very next characters in the real body are a tag-shaped token: an angle-bracketed object placeholder followed by an angle-bracketed id placeholder. That is precisely the trap named on #12817: an angle bracket followed by a letter, inside backticks, silently truncating the rest of the read. ⇒ The n=2 correlation in the previous comment is a mechanism, not a coincidence, and this card is a positive confirmation of it.

⛔ The body is deliberately NOT rewritten. Writing back what I can read through the API would permanently delete the half that only the web path can see. The recovery lives here, in a comment, per the standing rule.

The recovered body — the three sections that were lost

Everything from 复现步骤 onward was invisible to every API reader until now.

复现步骤

1. 任一自定义对象声明 sharingModel: 'public_read' + access: { default: 'private' };
2. 权限集给用户 allowRead + allowEdit(不带 modifyAllRecords);
3. 该用户对一条 owner_id 非本人(或为 null)的记录 by-id PATCH;
4. 403,message 为上述英文原文;前端(H5/自研客户端)展示原文。

期望

sharing 层的写/删拒绝复用与 record_access_denied 相同的 i18n 渲染机制(或给出稳定的 message key 供端上映射),让应用侧在任何一层被拒都能拿到本地化人话文案。

补充

• 实测来源:应用项目按记录属主收紧共享模式的交付自测,负例 REST 探针原文在私有应用仓留档,需要可提供;
• 与已关闭的 Console discards the server error message on 403, always showing the generic "no permission to save" string #7366(Console 丢弃服务端 403 文案)不同题:本单是服务端 message 本身未本地化。

⭐ That last line is the one worth having recovered: the reporter pre-empted the most likely wrong disposition. #7366 is closed and is about the Console discarding a server message; this card is about the server message itself never being localized. Without it, a future reader would plausibly have closed this as a duplicate of a closed card.

Premise re-verified on origin/main@f4e741bd1

Claim	Evidence
The hardcoded English refusal is still live	packages/plugins/plugin-sharing/src/sharing-plugin.ts:1119-1123 — new Error(`FORBIDDEN: insufficient privileges to ${op} ${ctx.object} ${id}`) , then err.code = 'FORBIDDEN'; err.status = 403;
The comparison the card draws is real	packages/plugins/plugin-security/src/security-plugin.ts:705 userFacingDenialMessage(...), called at :1938, :2059, :2295 with opCtx.context?.locale

⭐ The decisive finding: the catalog key already ships, and it names this card by number

packages/spec/src/system/operation-message.ts:13-17:

…and two 403 FORBIDDEN refusals whose keys land ahead of their emitters (#12493): the sharing middleware's by-id write denial (record_write_denied; emitter conversion is #12260's half) and plugin-approvals' non-submitter recall refusal (approval_recall_not_submitter; emitter conversion is #11993's half).

⇒ The spec half already landed under #12493. record_write_denied is a shipped key in all locales, and it was designed for this emitter — the module even explains why it is not record_access_denied restated:

the sharing middleware's by-id write gate fires on a row the READ path already admitted — the user is typically looking at the record it refuses — so "You do not have access to this record" would be false the moment it rendered. The situation is read-yes/write-no.

⇒ This card is not "add i18n to sharing". It is the outstanding consumer half of work already done, and it is the last of the pair: its twin, #11993's half, landed today as PR #12725.

Grading

finding → pm:queue, bug + domain:services retained. finding was never right for this one — it is a customer bug report, not something a seat recorded in passing; it was only ever carrying "awaiting first grading".

Clause-②: no. The key already exists, so the change is emitter-side in plugin-sharing with no packages/spec change, and the refusal's gate does not move — only the sentence. That is exactly how the twin (#12725) was graded, and it landed on that grading.

⇒ Dispatchable at this lane's ordinary tier, with an unusually complete brief: named emitter, named target key, and a merged same-lane precedent to mirror.

---

Generated by Claude Code