最新

标题基本上试图捕捉问题的要点。我被邀请（自愿）协助将一个专有的、成本较高的客户关系管理（CRM）解决方案迁移到Odoo社区“产品”，该产品将由专业合作伙伴进行架构设计、配置、部署在云服务上并进行运营。我的专业领域是基础设施（架构、运营和安全），因此我当然可以验证将应用功能映射到正确组件的过程，但我对CRM部分的优劣一无所知，尤其是如何在内部组织的志愿者没有技术技能的情况下，保持其可能需要的定制化和运营成本低廉。我担心集成商试图以一个可接受的一次性费用进入项目，然后在这个解决方案需要大量维护时逐渐提高价格。 有没有人有关于这个Odoo社区CRM产品和模型的经验，可以分享一些注意事项，以应对上述描述的使用尝试？用户最多300人。希望CRM还能够与所需的办公产品（文档、电子表格、电子邮件等）集成。

大多数允许用户部署代码的平台处理机密的方式都是一样的：把它们放在环境变量中，然后祝大家好运。我正在构建一个用于发布和重混可运行网页应用的小型社交平台（Vibecodr），当人们能够部署服务器端代码时，第一个请求是可以预见的：“让我用我的秘密调用一个外部API。” 环境变量的方法一直让我感到困扰。一旦你将明文交给用户代码，它就会存在于内存中，可能被记录、意外地在响应中回显，或者通过某个你没有审计的依赖悄悄泄露。当出现问题时，祝你好运找出秘密泄露的地方。 因此，我尝试设计一个更严格的约束：明文秘密绝不应存在于用户的工作内存中。无论是作为环境变量、帮助函数的返回值，还是在日志中。理想情况下，甚至连毫秒都不应存在。 以下是它的工作原理。 **调度层** 一个由平台控制的代理位于用户代码和外部世界之间。用户代码不会直接获取秘密。相反，它调用一个像fetch-with-secret的包装器，并传递： - 使用哪个秘密（密钥名称，而不是值） - 出站请求的详细信息 - 在哪里注入秘密（头部、查询参数、正文） 调度层负责敏感的工作：在服务器端解密秘密，验证出站URL（仅限HTTPS、可选的每个秘密的白名单、基础设施主机阻止、基于DNS的SSRF检查），以严格的超时发起上游请求，手动处理重定向并在每个跳转时重新验证，从文本响应中删除秘密，并强制执行配额。 **不透明令牌模式** 显式的fetch-with-secret API是安全的，但有时会显得笨拙——开发者喜欢正常地组合请求。因此还有第二种模式：用户代码请求一个短期的不透明令牌，用于给定的秘密密钥（仍然从未看到实际值）。如果该令牌出现在fetch的URL、头部或正文中，包装器会拦截它并通过调度进行真实的注入。令牌是每个请求的、短期的，只有在同一请求上下文中铸造的情况下才会解析。其他情况则会失败并关闭。 **密钥管理** 我对加密秘密负载格式进行版本控制，以便未来的迁移和密钥轮换不会产生歧义。支持多个候选解密密钥同时存在——可以在不破坏现有加密值的情况下进行轮换，并保持跨组件共享的加密逻辑，以避免实现之间的漂移。 **我实际遇到的陷阱** 重定向是一个安全陷阱。大多数HTTP客户端默认会跟随重定向，这可能会悄悄地将“允许的主机”转变为重定向到内部IP。每个跳转都必须手动处理重定向并重新验证，这是不可谈判的。如果我发布了天真的版本，这将会给我带来严重的问题。 删除机密比听起来要复杂得多。秘密可能以原始、URL编码或base64编码的形式出现在响应中。你希望实现深度防御，而不是让每个响应变得一团糟。短秘密会导致误报的删除——我选择了删除并发出警告，而不是跳过它们，因为“哎呀，泄露了”比“哎呀，损坏了”要糟糕得多。 你需要对所有内容设定严格的上限。请求正文大小、扫描的响应正文大小、超时上限。没有它们，每个“有用的功能”都可能成为拒绝服务攻击的向量。 **我希望得到的反馈** 我发布这个是因为我希望得到那些构建过类似系统或发现其漏洞的人的批评： - 你在安全处理二进制响应时，注入秘密的请求有什么首选策略？ - 你是否在边缘/无服务器环境中见过与基于DNS的SSRF验证相关的失败模式？ - 对于删除机密与如果可能包含秘密就完全阻止响应，你有什么强烈的看法？ 如果你想在真实产品上下文中看到这个项目，可以访问 https://Vibecodr.space——但我在这里是为了获取关于架构和威胁模型的反馈，而不是进行发布。

该平台提供关于您商业想法可行性的判定，以及其他因素，如竞争对手和市场研究、定价策略、90天计划等。我在这个平台上花了几个月的时间，以确保它不仅仅是另一个AI生成的粗糙产品。它遵循严格的结构化程序，且AI经过大量商业和公司数据、失败创业公司数据库等的训练。您可以免费试用，亲自体验一下:)

更改内容如下：<p>1) 更快的代理：现在在一个进程中创建多个TCP和UDP服务器实例（适用于Linux和Android）<p>2) 更好的数据包解析：DNS流量变得更加详细和稳健<p>3) 增加了更多的自动配置优化，并能够忽略某些端口<p>4) 许可证变更：从MIT迁移到GPLv3

免费获取来自全球领先科技公司的云积分、人工智能积分和开发者工具。

我创建了一个开源的Kubernetes操作器，用于自动化MLOps工作流中Jupyter Notebook的验证。它被称为Jupyter Notebook验证器操作器，旨在在Notebook进入生产环境之前捕捉潜在问题。 该操作器在隔离的Pod中运行Notebook，并能够将其与在KServe、OpenShift AI和vLLM等平台上部署的机器学习模型进行验证。它还通过将Notebook输出与“黄金”版本进行比较来进行回归测试。 我们的目标是提高Notebook在生产环境中的可靠性和可重复性。该操作器是使用Go语言和Operator SDK构建的。 我们正在寻找贡献者。欢迎参与开发更智能的错误报告、可观察性仪表板以及支持更多平台等功能。 GitHub: [https://github.com/tosin2013/jupyter-notebook-validator-operator](https://github.com/tosin2013/jupyter-notebook-validator-operator)

你好！希望以下内容足够不同以引起你的兴趣： 1) 我使用抽象语法树（Abstract Syntax Trees）让大型语言模型（LLM）修改现有代码。与Codex、Gemini CLI、Cursor等相比，它能够进行更有针对性的修改。如果你想了解更多，我写了一篇博客文章介绍我是如何做到的：<a href="https://codeplusequalsai.com/static/blog/prompting_llms_to_modify_existing_code_using_asts.html" rel="nofollow">https://codeplusequalsai.com/static/blog/prompting_llms_to_modify_existing_code_using_asts.html</a> 2) 我对令牌（tokens）进行双重收费。这创造了一个利润空间，当你发布应用时，可以从这额外的令牌利润中获利。一个对用户收费0.20美元的API调用，分解后是0.10美元给LLM提供商，0.08美元给你，0.02美元给我。我试图通过让收入在用户使用你的应用时自动产生，从而减少验证想法的摩擦。 3) 我建立了一个“市场”（Marketplace），你可以浏览人们创建的网络应用：<a href="https://codeplusequalsai.com/marketplace" rel="nofollow">https://codeplusequalsai.com/marketplace</a> 我想在AI世界中重新带回一种老派的网络氛围，让人们更容易创造东西，也能发现别人构建的小网站。我想知道是否可以通过将收入模型嵌入到你的网络应用中，来解决“微支付”（micropayments）这一从未真正起飞的想法。 4) 我设想未来的大规模软件开发将更加注重撰写清晰的任务单；我们都曾经历过撰写不佳的任务单、不明确的用例和模糊的需求。这个网站是我对未来用户体验的初步设想，在未来，撰写任务单可能会花费更多时间，尤其是在编码方面。 你觉得怎么样？ -- 一些关于幕后技术的快速细节：这个系统运行在3台Linode服务器上：1台应用服务器（Python/Flask），1台数据库服务器（Postgres），1台“Docker服务器”，用于托管你的网络应用。制作这个系统最困难的部分是让LLM编写AST代码，并设置运行它的基础设施。我有一个封闭的Docker环境，里面有Python和Node，一旦LLM响应代码修改请求，我们就在这个Docker中运行一个脚本以获取新的输出。例如，要修改一个HTML文件，它会运行一个Python脚本，将原始文件内容作为字符串输入LLM输出，LLM使用BeautifulSoup根据用户的请求对HTML文件进行修改。每种语言的定制程度都很高，目前我支持Python、JavaScript、HTML、CSS，并正在测试React/TypeScript（取得了适度的成功！）