feat(pcview): add host webui access - #39
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthrough新增 ChangesHost WebUI 功能
独立小修改
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@entry/src/main/ets/pages/HostWebUiPage.ets`:
- Around line 198-205: The early return statement when acceptedSslError is true
prevents the subsequent error handling code from executing, which means
isLoading remains true and the error panel never appears for real framework
errors like connection refusal or timeout. Remove or restructure the early
return in the acceptedSslError check so that the subsequent code block that sets
isLoading to false and populates loadError with the error description continues
to execute regardless of whether an SSL error was previously accepted. This
ensures that actual errors from the main framework are properly handled and
displayed to the user.
- Around line 179-192: The WebView configuration combines two dangerous security
practices: MixedMode.All allows HTTPS pages to load unencrypted HTTP resources
(forbidden in production), and unconditionally calling
event.handler.handleConfirm() in the onSslErrorEventReceive callback bypasses
certificate validation, exposing the app to man-in-the-middle attacks. Fix this
by changing mixedMode from MixedMode.All to MixedMode.None for strict HTTPS-only
mode, and either remove the onSslErrorEventReceive callback entirely to let the
system reject unsafe connections by default, or if custom SSL handling is
required, replace event.handler.handleConfirm() with
event.handler.handleCancel() to abort insecure connections. Self-signed
certificates should be resolved by installing legitimate CA certificates to the
system trust store rather than bypassing validation in code.
- Around line 120-129: The openInBrowser method calls context.startAbility(want)
which returns a Promise, but the current code does not await it, causing Promise
rejections to not be captured by the try/catch block. Make the openInBrowser
method async and add await before context.startAbility(want) so that any errors
from the Promise rejection are properly caught by the existing try/catch error
handler.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 1357d463-afb6-47ab-8e31-ef822cc4e68b
📒 Files selected for processing (7)
entry/src/main/ets/pages/HostWebUiPage.etsentry/src/main/ets/pages/Index.etsentry/src/main/ets/pages/PcListPageV2.etsentry/src/main/ets/pages/SettingsPageV2.etsentry/src/main/ets/utils/HostWebUiUtil.etsentry/src/main/ets/viewmodel/ComputerMenuHelper.etsentry/src/main/resources/base/profile/main_pages.json
| .mixedMode(MixedMode.All) | ||
| .zoomAccess(true) | ||
| .onPageBegin(() => { | ||
| this.isLoading = true; | ||
| this.loadError = ''; | ||
| }) | ||
| .onPageEnd(() => { | ||
| this.isLoading = false; | ||
| }) | ||
| .onSslErrorEventReceive((event) => { | ||
| this.acceptedSslError = true; | ||
| this.loadError = ''; | ||
| event.handler.handleConfirm(); | ||
| }) |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
HarmonyOS ArkWeb 中 mixedMode(MixedMode.All) 与 onSslErrorEventReceive 直接 handleConfirm() 的官方安全建议是什么?生产环境是否建议自动确认所有 SSL 错误?
💡 Result:
根据华为HarmonyOS官方开发者文档及安全编码规范,针对ArkWeb组件中 mixedMode 和 SSL 错误处理的官方安全建议如下: 1. 关于 mixedMode(MixedMode.All) 的建议 官方强烈建议禁止在生产环境中使用 MixedMode.All(宽松模式)[1][2][3]。 配置为 MixedMode.All 会允许 HTTPS 页面加载 HTTP 资源,从而破坏 HTTPS 通信的完整性,引入中间人攻击风险[1][2]。 官方推荐做法是将 mixedMode 配置为 MixedMode.None(严格模式),从根源上规避混合内容安全风险,并建议推动服务器将所有 HTTP 资源链接迁移至 HTTPS[1][2]。 2. 关于 onSslErrorEventReceive 中调用 handleConfirm 的建议 官方明确禁止在 onSslErrorEventReceive 或 onSslErrorEvent 回调中调用 event.handler.handleConfirm [2][3]。 直接忽略 SSL 错误并继续加载会绕过系统的证书校验机制,直接暴露于中间人攻击的风险中[3]。 3. 生产环境的官方处理建议 官方建议在处理 SSL 错误时采取以下合规方式: 不实现 onSslErrorEventReceive 或 onSslErrorEvent 回调,此时系统会默认取消资源加载,这是最安全的默认行为[1][3]。 若需要自定义处理,应在回调中主动调用 event.handler.handleCancel 来显式中止不安全的连接[1][2][3]。 如遇到自签名证书导致校验失败,生产环境的正确解决方案是使用合法 CA 签发的证书,或将所需的 CA 证书正确安装到系统的受信任证书存储中,而非通过代码手段绕过校验[4][5][6]。 综上,生产环境严禁自动确认所有 SSL 错误,这被视为严重的安全风险行为[2][3][6]。
Citations:
- 1: https://www.infoq.cn/article/MqHM9y9d5fdhY53vSoqI
- 2: https://www.woshipm.com/share/6400678.html
- 3: https://harmonyosdev.csdn.net/6a1035fe10ee7a33f2746e80.html
- 4: https://bbs.itying.com/topic/6843a8814715aa008847b6e5
- 5: https://bbs.itying.com/topic/690c6ee8a24f9e0042b6c15f
- 6: https://www.woshipm.com/share/6400669.html
禁止在生产环境组合使用 MixedMode.All 和无条件 SSL 错误确认。
第 179 行的 MixedMode.All 与第 191 行的 event.handler.handleConfirm() 无条件确认构成高危配置:
- 混合内容风险:MixedMode.All 允许 HTTPS 页面加载 HTTP 资源,HarmonyOS 官方文档明确禁止在生产环境使用,会破坏 HTTPS 通信完整性。
- 证书绕过风险:官方明确禁止在
onSslErrorEventReceive中调用handleConfirm(),此做法直接绕过系统证书校验,暴露于中间人攻击。页面处理 Basic Auth 会进一步放大凭据泄露风险。
修复方案:
- 将
mixedMode改为MixedMode.None(严格模式)。 - 移除
onSslErrorEventReceive回调让系统默认取消不安全连接;或若需自定义处理,改为调用event.handler.handleCancel()中止连接。 - 对自签名证书,应通过安装合法 CA 证书到系统受信存储解决,不应通过代码绕过校验。
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@entry/src/main/ets/pages/HostWebUiPage.ets` around lines 179 - 192, The
WebView configuration combines two dangerous security practices: MixedMode.All
allows HTTPS pages to load unencrypted HTTP resources (forbidden in production),
and unconditionally calling event.handler.handleConfirm() in the
onSslErrorEventReceive callback bypasses certificate validation, exposing the
app to man-in-the-middle attacks. Fix this by changing mixedMode from
MixedMode.All to MixedMode.None for strict HTTPS-only mode, and either remove
the onSslErrorEventReceive callback entirely to let the system reject unsafe
connections by default, or if custom SSL handling is required, replace
event.handler.handleConfirm() with event.handler.handleCancel() to abort
insecure connections. Self-signed certificates should be resolved by installing
legitimate CA certificates to the system trust store rather than bypassing
validation in code.
改了啥呀
为啥要改
验证
git diff --checkNODE_PATH=/Users/mac/Program/moonlight-harmony/node_modules JAVA_HOME=/Applications/DevEco-Studio.app/Contents/jbr/Contents/Home DEVECO_SDK_HOME=/Applications/DevEco-Studio.app/Contents/sdk node hvigorw.js assembleApp --no-daemonhttps://192.168.18.42:47990,出现 Sunshine WebUI 登录弹窗。Summary by CodeRabbit