Conversation
…_ORIGIN Add an explicitly named ValidateCoreURLAllowingInsecure variant and select it in publicURL when the installer-derived OAC_ALLOW_INSECURE_ORIGIN is "1". ValidateCoreURL keeps its signature and default contract, so a Core without the switch behaves exactly as before and the shared origin vectors stay unchanged. The relaxed origin still derives ws:// through runtimeWebSocketURL, so the Runtime gateway starts on a plain HTTP public URL. Co-authored-by: multica-agent <github@multica.ai>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 219bb86100
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // allowInsecureOrigin reads OAC_ALLOW_INSECURE_ORIGIN, which the installer | ||
| // derives from config.json allow_insecure_origin. It is never inferred from | ||
| // OAC_PUBLIC_URL or read from another variable. | ||
| func allowInsecureOrigin() bool { | ||
| return os.Getenv("OAC_ALLOW_INSECURE_ORIGIN") == "1" |
There was a problem hiding this comment.
When this runs through the supported oac apply installer, allow_insecure_origin is rejected by config.schema.json and configuration.core_environment never emits OAC_ALLOW_INSECURE_ORIGIN; therefore a non-loopback http:// public_url still makes Core fail startup, and hand-editing generated/core.env is rejected on the next apply. Render and document the switch as a process setting so the advertised managed-installation path can actually enable it.
AGENTS.md reference: AGENTS.md:L46-L48
Useful? React with 👍 / 👎.
1 participant
目标
OAC-3：Core 在
OAC_ALLOW_INSECURE_ORIGIN打开时接受非 loopback 的http://public origin，并正常派生ws://daemon URL、启动 Runtime gateway；默认关闭时行为与现状完全一致。消费 OAC-2（#2）派生的
OAC_ALLOW_INSECURE_ORIGIN="1"（config.json顶层allow_insecure_origin）。改动（仅
services/core）services/core/internal/deployment/public_url.go：新增导出变体ValidateCoreURLAllowingInsecure，与ValidateCoreURL共享同一私有实现；唯一差异是开启时额外接受非 loopback 的httpscheme。ValidateCoreURL的签名与语义保持不变，共享向量不弱化。变体导出，供 OAC-4 复用同一判定。services/core/cmd/server/process_configuration.go：publicURL()读取OAC_ALLOW_INSECURE_ORIGIN（仅"1"视为开启，遵循仓库派生布尔惯例如OAC_LOG_ADD_SOURCE，不做别名/fallback），开启时选择放宽变体。默认关闭时错误信息与行为逐字节不变。services/core/internal/deployment/rules_test.go：ValidateCoreURLAllowingInsecure接受非 loopbackhttp://IP（含 IPv6），仍拒绝非法形态；并断言ValidateCoreURL仍拒绝非 loopback HTTP。services/core/cmd/server/process_configuration_test.go：开关未设/为"0"/"true"/"yes"/"2"时拒绝非 loopback HTTP；开关为"1"时接受并原样返回，且runtimeWebSocketURL派生ws://10.0.0.5:8080/api/v1/agent-daemon/ws；开关开时仍拒绝非规范 origin。services/core/cmd/server/daemon_bootstrap_test.go：runtimeWebSocketURL的https→wss/http→ws映射，含非 loopback 与 IPv6。未改动 installation facts：Web 从自身 env 读取该开关（OAC-2 已写入 web env），无需扩张 Core API。未触碰
deploy/install（OAC-2 范围）与ValidateCoreURL契约。验证
make check-runtime-contractmake check-coreservices/core/internal/deployment、services/core/cmd/server等 54 个包 ok；check-core-store461 tests ok；两个 Python 测试 ok；仅services/core/internal/nativeinstaller失败（见下）make check-namespython3 scripts/ci_plan.py plan --base origin/main --head HEADmake check-core的失败与本改动无关，且在本环境未改动的origin/main（28d34ff0，clean tree）上同样复现：TestBootstrapCommandDiscardsTimedOutResponse：环境 curl 7.29.0/NSS 对--max-time 0.3报 “expected a proper numerical parameter”。TestBootstrapDownloadsVerifiedPlatformAcrossHTTPSRedirect：curl 7.29.0/NSS 拒绝 httptest 证书（Certificate type not approved for application）。OAC_TEST_DATABASE_URL未配置，store 集成测试按设计 skip（package ok）。已知限制
OAC_ALLOW_INSECURE_ORIGIN=1时生效，此时凭据/API key 走明文，仅面向开发/测试场景。InsecureSkipVerify。Refs: OAC-3；依赖 OAC-2 #2 派生的 env 名与值。