@COW 因为我们使用 IAM 的目的是为我们自己的应用云平台上的所有 SaaS 或 On-Permis 应用提供统一的认证和鉴权框架，包括我们自己的应用云平台上的 Open API 类产品也是托管在我们平台上进行认证和鉴权的，这种场景的细粒度授权 RBAC 不合适所以我们自己基于 Keycloak 封装了一套 PBAC

1. 关于你说的利用 LDAP 集成，这边建议是统一采用泛用性更强的 OIDC 协议
2. Keycloak 的 Audit 和其他系统的 Audit 并不相同，Keycloak 的 Audit 更关注的是认证与授权事件的审计，而类似于 Jenkins 等系统的审计更关注的是系统本身的业务操作审计
3. Keycloak 的角色权限较为复杂，Authorization 功能也仅限于 OIDC 协议使用，如果需要做集成的话可能需要对客户端（类似但不限于 Jenkins 、Gitea 等）做二次开发才能够实现

P.S. 我们对于 Keycloak 的 Authorization 等概念做了一些更高层的抽象，并且我们的鉴权模型为 PBAC ，我们的做法是通过开发 Keycloak 插件将 Authorization 内的一些概念类似但不限于 Permission, Scope, Resource 等与 PBAC 中的概念做了一一映射。

我们在用它搭建企业内的 IAM ，你的问题是什么呢？

2024 年初我测试还是难用，目前 Remote 体验最好的还是 VSCode

估计是 AI 生成用来混大量 PR 的 建议 revert 很多地方直接变量可以做到自注释，简单的逻辑也不需要太细致入微注释

talk is cheap. show me the code

好烦啊 怎么天天都能看见你？这样就算项目再好用、优秀我也烦了 屏蔽了 这个项目我一个 star 也不会点 也不会推荐给别人

Linux on Vmware + VSCode Remote Development ，我习惯用 VSCode 写 Java 和各种所以这套反而用的很舒服

tailscale

确实不稳定了最近，已经弃坑不用了，还好当是只充了 50 ，感觉最近价格突然贵起来了

哈哈哈 火星了
@lanlanye

虽然 Nix 的理念是好的，但是还是脱离了主流发行版的固定模式了，表面看起来的优雅带来的是无尽的兼容性的痛苦，Nix 的想法太超前了，以至于发展这么长时间也没有大面积的流行起来，受众面积还是太小了，适合实验和学习，真正投入生产还是需要观望

我是 Arch Linux + Gnome ，同版本，在打开飞书之后会导致某些键位失灵，不一定是 Backspace ，我这边有时候会是数字 1 键失灵

@sztink 学到了 谢谢

1. 找到感兴趣的项目
2. 查看 Issues
3. 找到感兴趣的 Issues
4. 阅读项目的 CONTRIBUTE 指导
5. Fork Repo 到自己的账户
6. 按照 Issue 内容进行改动并提交
7. 创建 Pull Request 到上游仓库
8. 等待上游仓库的 Maintainers 检查你的 PR 内容并合并，如果 Maintainers 有在你的 PR 里留言讨论你的代码要及时响应
9. 如果你的 PR 被合并，恭喜你完成了一次贡献

这样写不是闲的吗？同事应该会打人吧（逃

谢谢各位

好丑的设计 :)