24小时热榜

我花了 4 年时间试图构建这个 OAuth 服务器，但从未完成。<p>然后我发现了基于 Agent 的编码方式，并在 3 周内就发布了它。<p>它的与众不同之处：<p>• 两个 AI Agent 在 300 毫秒内分析每次登录 - 安全信号 Agent：风险评分（设备、IP、地理位置、速度） - 策略合规 Agent：业务规则（MFA 策略、角色强制执行） - 综合决策：允许/记录/升级/锁定/拒绝<p>• 生产就绪的安全性 - PKCE (RFC 7636), DPoP (RFC 9449) - MFA (TOTP + WebAuthn/通行密钥) - IP 限制、速率限制、审计跟踪<p>• 欧盟数字主权 - 原生 GDPR (数据导出、法律保留、保留策略) - 欧盟托管，无美国云法案风险 - 完整的审计跟踪 (PostgreSQL + Redis Streams)<p>• 零 AI 依赖 - 如果 AI 超时，则进行确定性回退 - 返回保守的 MEDIUM 风险（安全默认值） - 系统在没有外部 LLM 调用的情况下持续运行<p>• 现代技术栈 - 后端：NestJS + TypeScript, LangChain/LangGraph - 前端：React 19，六边形架构，91% 的测试覆盖率 - 如果 AI 超时，则进行确定性回退（零依赖）<p>构建此系统是为了替代 Firebase Auth / AWS Cognito / Auth0，适用于希望控制其身份验证基础设施的公司。<p>仓库中有架构图和截图。<p>欢迎反馈和提问。

大家好， 我一直在开发 dbt-Workbench，这是一个开源 UI，用于在 CLI 之外使用 dbt 项目。<p>目标很简单：让 dbt 工件（模型、源、测试、血缘关系、运行）更容易查看和理解，尤其是在 dbt 文档开始感觉受到限制的大型项目中。<p>这最初是我在使用复杂的 dbt 设置时遇到的一个个人痛点，我决定清理它并公开发布。<p>它还处于早期阶段，有自己的观点，而且肯定不完美。我非常感谢大家的反馈，特别是那些大规模使用 dbt 的人。很乐意回答问题或听取大家认为这是否是个坏主意的看法。<p>仓库：<a href="https:&#x2F;&#x2F;github.com&#x2F;rezer-bleede&#x2F;dbt-Workbench" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rezer-bleede&#x2F;dbt-Workbench</a>