Resource actions that need a signed-in user ('signed-in' access)

未关闭
  • 哪里不对？
#163 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
24/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
angular, supabase, typescript
领域
authentication, backend-api-design, full-stack

调研方向

Start with libs/core/src/lib/resource.ts and libs/core/src/lib/is-resource-action-enabled.ts, then trace the session from injectAuthSession() into the route guards in libs/demo-shared/src/lib/can-match-resource-action.ts and libs/cli/src/lib/generated-pages.ts. Read discussion #113 alongside this proposal, then follow the listed demo, CLI wizard, generated pages, and documentation entry points. Done means every listed action, generator path, and docs requirement works as specified, with existing booleans and apps without auth retaining their behavior.

由索引模型根据 Issue 内容生成。

描述

enhancement layer: library pkg: cli pkg: core pkg: material pkg: tailwind

Why

Today a Resource turns each action on or off for everyone: list, create, show, edit and delete are boolean (libs/core/src/lib/resource.ts). An app cannot say "visitors may read, only signed-in users may write", or "this table is only for signed-in users, even if Row Level Security lets anyone read it".

The quick fix planned for 0.1.1 (#162: hide Create, Edit and Delete when nobody is signed in) only guesses. This issue is the real design, planned for 0.2.0.

Proposal

Let each action take a third value, 'signed-in':

// resources.ts
{
  name: 'products',
  list: true,          // everyone
  show: true,
  create: 'signed-in', // hidden until someone signs in
  edit: 'signed-in',
  delete: 'signed-in',
}
{
  name: 'staff_notes',
  list: 'signed-in',   // no menu entry and a guarded route when signed out
  show: 'signed-in',
}
  • true: everyone. false: nobody. 'signed-in': only a signed-in user.
  • The type becomes boolean | 'signed-in'. Existing resources.ts files keep working without any change.
  • An app-wide default avoids repeating the same value on every resource, and each resource can still override it. For example: signedOut: 'read-only' | 'hidden' | 'full'. The exact name and place (providePidrang() or the resources provider) are to be decided in this issue.
  • pidrang init writes these values from its answers. It already asks whether the tables need a signed-in user to be read (libs/cli/src/lib/wizard.ts). It should also ask about writes, with "signed-in" as the default.

Important

Hiding is not security. Row Level Security in the database stays the only protection. The UI only follows what the app declares, and the docs must say so.

The browser cannot read RLS policies with the publishable key, so the values are declared, not detected. Reading pg_policies during init to suggest answers could come later.

Where it touches

  • libs/core: Resource, isResourceActionEnabled() (libs/core/src/lib/is-resource-action-enabled.ts), the session from injectAuthSession().
  • Route guards: libs/demo-shared/src/lib/can-match-resource-action.ts and its copy in libs/cli/src/lib/generated-pages.ts.
  • Menu and pages in both demos and in the generated pages (pnpm run sync:pages).
  • pidrang init: wizard questions, --plan keys, the generated resources.ts.
  • Docs: docs/authentication.md, the CLI reference, a migration note.

Design this together with the hidden redesign planned for 0.2.0 (discussion #113): both change what a Resource declares per action and per page.

Done when

  • 'signed-in' works for every action in both UI layers: buttons, menu entries and route guards follow the session, with no page reload.
  • Apps without an auth provider behave as today.
  • Existing boolean values behave as today (covered by tests).
  • pidrang init asks the questions and writes the values. --plan supports them.
  • Docs explain the values, the app-wide default, and that RLS stays the protection.
  • The 0.1.1 quick fix from #162 is replaced by this design.
主要语言
TypeScript
星标
2
派生
2
平均合并
9 小时 17 分钟
30 天内合并 PR
48

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

pidrang/pidrang 的其他 Issue

查看 pidrang/pidrang 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。