@veotax ？这是一个东西吗？别瞎推广行吗？

not impressed, 从 4.0 版本开始就料到迟早会进行闭源的, 4.0 的整体架构设计在商业层面就是为了进一步商业化推进

@Aether sorry, 这个确实是我的 wx ，但是不知为何您无法找到，您可以尝试通过 MTc2MjEyMjYzNzE=这个号码找到我

哇 连个回复都没有 我已经退坏境了吗 :(

run

@sunzhenyucn 这里最重要的、具有挑战性的是如何配合智库团队理解他们的工作思维和方式，将其“教”给模型，反而技术层面都是次要的了

不少都是在圈地自萌，没有需求凭拍脑袋造需求。
我这里倒是最近 focus 在一个比较具有挑战性的需求上：
结合当地智库团队的思维能力和经验，将其固化给模型，并配合自建的工具或自托管 MCP Server ，结合将智库近年来的一些知识文档和互联网搜索能力实现 Deep Research ，为智库编写内参或研究报告提供生成工具，最终在软件形态上会是一个 MAS

Wiz 的报告我也看了，虽说前面的层主有提到过确实有安全大佬在幻方，但依照结果来看确实有些地方犯了一些本不应该去犯的错误

Ingress, Ingress 不只是为 http 类端口服务的, 你像 APISIX 就提供了 Stream Proxy 来帮助代理基于 TCP 或 UDP 协议的面向流式的流量, 不过这并不是一个银弹, 适用场景可以参考官方文档。

P.S. 无利益相关

@qiujianzhong 正在准备，准备好之后发给您

@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