Arki 的每日 BUG 观察

https://minds.md/zakirullin/cognitive

#优质博文#前端#权限控制#全栈 好文。 Choosing the best access control model for your frontend AI 摘要：本文探讨了前端应用中最佳访问控制模型的选择，重点分析了 RBAC（基于角色的访问控制）、ABAC（基于属性的访问控制）、ACL（访问控制列表）和 PBAC（基于策略的访问控制）的优缺点。作者指出，虽然不同模型各有适用场景，但 RBAC 因其简单性、可扩展性和与前端框架（如 React/Next.js）的良好兼容性，成为大多数前端应用的首选方案。文章还通过 Next.js 示例演示了 RBAC 的具体实现，并讨论了混合模型的潜在应用场景。 1. 访问控制的核心作用 • 前端访问控制的核心目标是优化用户体验（而非安全 enforcement），通过动态显示可交互的 UI 元素减少用户困惑。 2. 主流访问控制模型对比 • RBAC（基于角色的访问控制 role-based） • 通过用户角色分配权限，适合大多数前端应用 • 优势：易于维护、性能良好、与前端框架集成度高 • 局限：缺乏细粒度控制（如无法处理动态条件） • ABAC（基于属性的访问控制 attributes-based） • 根据用户/环境属性动态决策 • 适用场景：需要实时权限变更的复杂系统 • 前端缺陷：性能开销大、状态管理复杂 • 简单解释一下，这就像说，“如果用户的部门是 X，文档是 Y 分类的，并且是在工作时间，那么允许访问。 • ACL（访问控制列表 access control list） • 用于在单个资源级别定义权限。这意味着访问权限直接分配给特定用户或组 • 前端痛点：权限列表扫描导致性能下降，难以扩展 • PBAC（基于策略的访问控制 policy-based） • 依赖中央策略引擎（如 OPA）动态评估规则 • 建议仅限后端使用，前端实现会导致界面延迟和闪烁 • 它在后端服务中大放异彩，尤其是在微服务架构中，您希望跨 API 实现集中、一致的策略实施。 3. RBAC 的 Next.js 实现示例 • 演示项目结构：角色配置（roles.js）、自定义钩子（useRBAC）、动态仪表盘（Dashboard.js） • 关键功能： • 基于角色的 UI 元素显隐控制 • 受保护路由（如 /admin）的权限验证 • 无权限用户的 403 重定向 4. 混合模型的应用 • RBAC + ABAC：角色基础规则 + 属性动态补充（如部门限定访问） • RBAC + ACL：角色为主，ACL 处理特殊例外（需谨慎使用） • PBAC 应严格限于后端 API 层 5. 结论与建议 • 前端访问控制的本质是用户体验优化 • RBAC 是大多数场景的最佳平衡选择 • 复杂场景可谨慎组合模型（如 RBAC+ABAC） • 强调：前端控制需与后端安全验证配合 author Temitope Oyedele

📖 How the Raycast API and extensions work #article 备注：raycast 的体验真的甩同类 Alfred 已经太远了，解读技术实现的文章也很清晰 https://www.raycast.com/blog/how-raycast-api-extensions-work

https://animations.dev

lucia-auth 作者写了一本小册，https://thecopenhagenbook.com 介绍了常见的 Auth 的一些实现，质量非常高。强烈推荐

首先众所周知 setTimeout 是平台的 API，可以直接判断平台 API 在所有 promise 后面走 event loop（不过现在有个例外 queueMicrotask，平台 API 但是不是 event loop，这个倒是可以搞到 JS 规范里）。 然后我对代码执行的建模是这样的： Promise Reaction Job 队列（微任务队列）里面存了已经解决的 Promise 的 Reaction（then/catch/finally） 开始执行代码时，（初次运行时）先执行所有同步的代码， 然后按顺序执行所有的 Promise Reaction Job 里的 Reaction。 执行代码时新解决的 Promise 上面挂的 Reaction 就会推到队列里。 全部执行完毕之后 idle，等待 event loop 中的事件触发下一次执行代码。 对于上面的代码，我的理解过程是这样的（不提 setTimeout 因为肯定是最后一个）： line 5:首先同步执行 promise 的构造器，log-promise 然后直接解决了 promise（也就是说接下来附加到这个 promise 的 reaction 会直接进队列），目前队列是空的，因为 promise 没有 reaction。 line 10: async iife 和 new Promise 没什么区别，所以 log async start。 line 12: await promise 了（参考规范 27.7.5.3），首先判断是不是平凡的 Promise，如果不是还得包一层（step 2）。 生成两个 reaction，一个是被 await 的 promise resolve 了之后执行的代码，一个是 reject 之后（step 3 和 5）。 然后规范 step 7 直接执行了 promise.then(第一个 reaction，第二个reaction），然后暂停了当前 async function 的执行。 因为 promise 已经解决了，所以把第一个 reaction 排进队列（队列里的第一个 reaction） line 16: 再给 promise 挂一个 resolve reaction。同理，进队列，排在上面那个的后面 line 20: log-end 此时同步代码已经执行完了，接下来按顺序执行队列打出 promise resolve 和 log-promise1-then。 假如在 line 13 前面加 promise.then(() => ...)，那它按队列，排在 log-promise1-then 后面。

https://github.com/Luka-Teng/deepInWebpack/blob/9746ad3cd7f3aec84e6f5c17fb9e6e7f4bf8632a/webpackSource/myPlugin.js

https://loro.dev/blog/movable-tree

https://prin.pw/react-unstable-nested-components/

https://colinhacks.com/essays/live-types-typescript-monorepo

https://rubenpieters.github.io/programming/typescript/2018/07/13/existential-types-typescript.html