鸿蒙webview开发中web内部网络请求访问资源跨域问题,客户端解决方案

鸿蒙webview开发中web内部网络请求访问资源跨域问题,客户端解决方案

项目场景:

在鸿蒙系统的h5混合开发过程中,我们使用web组件进行混合开发,后台并未对跨域问题进行处理,web组件内部发送网络请求出现访问资源跨域问题。


问题描述

访问资源跨域是浏览器在发送网络请求时经常遇到的问题,而鸿蒙的web组件也就相当于一个浏览器,因此在web组件内部发送,也会出现跨域问题,这种问题一般需要再后台解决,但是鸿蒙官方也有提供客户端解决跨域的方案,官网:解决Web组件本地资源跨域问题-管理Web组件的网络安全与隐私-ArkWeb(方舟Web)-应用框架 - 华为HarmonyOS开发者


原因分析:

为了提高安全性,ArkWeb内核不允许file协议或者resource协议访问URL上下文中来自跨域的请求。因此,在使用Web组件加载本地离线资源的时候,Web组件会拦截file协议和resource协议的跨域访问。可以通过方法二设置一个路径列表,再使用file协议访问该路径列表中的资源,允许跨域访问本地文件。当Web组件无法访问本地跨域资源时,开发者可以在DevTools控制台中看到类似以下报错信息:

官方解决方案描述:

在鸿蒙官网,提供了两种解决方案:

一、为了使Web组件能够成功访问跨域资源,开发者应采用http或https等协议,替代原先使用的file或resource协议进行加载。其中,替代的url域名为自定义构造的仅供个人或者组织使用的域名,以避免与互联网上实际存在的域名产生冲突。同时,开发者需利用Web组件的onInterceptRequest方法,对本地资源进行拦截和相应的替换。

二、

通过设置设置一个路径列表。当使用file协议访问该列表中的资源时,允许进行跨域访问本地文件。此外,一旦设置了路径列表,file协议将仅限于访问列表内的资源(此时,fileAccess的行为将会被此接口行为覆盖)。路径列表中的路径必须符合以下任一路径格式:

1.应用文件目录通过Context.filesDir获取,其子目录示例如下:/data/storage/el2/base/files/example/data/storage/el2/base/haps/entry/files/example

2.应用资源目录通过Context.resourceDir获取,其子目录示例如下:/data/storage/el1/bundle/entry/resource/resfile/data/storage/el1/bundle/entry/resource/resfile/example

当路径列表中的任一路径不满足上述条件时,系统将抛出异常码401,并判定路径列表设置失败。若设置的路径列表为空,file协议的可访问范围将遵循fileAccess的规则。

解决方案:

由于本人在开发过程中使用到了第二种解决方案, 在这里本人提供具体的操作步骤,以及指出本人踩过的坑点。

在web组件上本使用的是  resource:// 协议去访问资源,使用如下 X:

 Web({ src: 'resource://rawfile/dist/index.html#/xxxx', controller: this.webController })

然而setPathAllowingUniversalAccess 属性需要读取的是/data/storage/el1/bundle/entry/resource/resfile目录下的文件,使用Context.resourceDir获取到的路径为空

原来是在项目创建时并不会自动生成resfile文件,需要我们手动创建,在项目的src/main/resources下新建文件夹:resfile

将打包好的dist文件,也就是h5页面文件,放在resfile文件夹下面,通过以下方法读取文件   

web({ src:'resource://resfile/dist/index.html#/xxxxxxx', controller: this.webController })

 做好以上步骤之后,就来到了解决跨域最为关键的点:

设置setPathAllowingUniversalAccess,这里需要指定解除跨域的文件

 // 在设置好setPathAllowingUniversalAccess 之后,需要将src置空,使用loadUrl加载页面 Web({ src: "", controller: this.webController }) .onControllerAttached(() => { try { // 设置允许可以跨域访问的路径列表 this.webController.setPathAllowingUniversalAccess([ // 这里获取到resfile文件目录,后边拼上自己的h5文件 getContext().resourceDir + "/dist/index.html" ]) this.webController.loadUrl('原页面路径') } catch (error) { console.error(`ErrorCode: ${(error as BusinessError).code}, Message: ${(error as BusinessError).message}`); } }) .javaScriptAccess(true) .fileAccess(true) .domStorageAccess(true)

 至此即成功使用官方的第二种方法去在客户端解决咱们在鸿蒙+h5的混合开发中的h5页面跨域问题了

Read more

WorkBuddy:普通人的 AI 门槛,被它彻底抹平了

WorkBuddy:普通人的 AI 门槛,被它彻底抹平了

很多粉丝加了我微信,第一件事情都是问:一人公司怎么玩? 龙虾怎么玩? AI 助理怎么搭?  我的回答都是劝退:龙虾目前是技术极客的玩具,普通人能安装但很难维护,随便出点问题就卡住了!  但现在,我要收回我的说法了,因为 WorkBuddy 出现了。 大家好,我是小虎。 这周,我用 WorkBuddy 做了一件事:上传一份脚本文件,说了一句话,它帮我生成了一个多角色配音、有字幕、有情绪起伏的正式视频。 我啥都没干,去泡了杯茶,回来视频在那里。 普通人被卡在哪里了 在说 WorkBuddy 能做什么之前,我想先说一件真实发生的事。 有一个粉丝,在我的 AI 培训班上认认真真学完了全程。 结课的时候他说:小虎老师,我觉得我学懂了,但回去之后还是不知道从哪里开始用。 这不是个例。这是我在杭州、温州、嘉兴、义乌、安徽望江跑了那么多场培训下来,见到最多的情况。 大家不是不努力,

惊魂零点击!OpenClaw漏洞(ClawJacked)突袭,开发者AI Agent遭无声劫持

在AI Agent快速普及、成为开发者高效辅助工具的当下,一场针对开发者群体的高危零交互攻击悄然爆发。OpenClaw 0-Click漏洞(代号ClawJacked,CVE-2026-25253)凭借“零点击、全静默、高权限”的特性,成为AI工具生态中极具破坏性的安全隐患——攻击者无需诱导用户点击、安装插件或确认弹窗,仅需让开发者访问一个恶意网页,就能轻松劫持其本地运行的OpenClaw AI Agent,进而获取系统级控制权,窃取核心开发资产、执行恶意命令,对个人开发者、企业研发团队造成不可挽回的损失。作为AI Agent领域首个被公开披露的高危零点击漏洞,ClawJacked不仅暴露了OpenClaw的设计缺陷,更给整个AI工具生态敲响了安全警钟。 本文将从漏洞核心原理、完整攻击链路、潜在危害、根本成因、修复防护方案五个维度,进行专业、全面的解析,并结合行业现状给出前瞻性警示,帮助开发者、企业快速识别风险、筑牢安全防线。 一、漏洞核心原理(深度解析) OpenClaw 0-Click漏洞的本质,是其本地网关设计存在三大致命逻辑缺陷,叠加浏览器对本地回环地址(localhos

手把手教你使用 YOLOv11/v8 算法 + PaddleOCR 算法完成车牌检测和车牌识别系统,AI智能体,毛玻璃系统,包括PaddlePaddle安装、数据集预处理、模型训练、AI大模型应用等

手把手教你使用 YOLOv11/v8 算法 + PaddleOCR 算法完成车牌检测和车牌识别系统,AI智能体,毛玻璃系统,包括PaddlePaddle安装、数据集预处理、模型训练、AI大模型应用等

前言 车牌识别系统是智能交通、安防监控等领域的关键技术,结合深度学习方法可提升识别模型准确率。本文基于YOLOv11/v8 目标检测模型与PaddleOCR 文本识别模型结合,实现端到端的车牌定位与字符识别。之前出过一期基于YOLOv11+CNN 车牌识别系统,链接如下: * 手把手教你完成基于YOLOv11+CNN车牌识别系统,Opencv车牌矫正,基于深度学习的车牌识别系统 由于 YOLOv11+CNN 车牌识别系统对倾斜角度较大和模糊的图片识别效果不佳、识别车牌单一、界面功能和样式单一等问题,本期将进行升级,本期整合了 YOLOv8/YOLOv11 + PaddleOCR + PySIde6 搭建一个车牌识别系统,有用户端系统+后台管理系统。技术路线如下: 1. 先利用YOLOv8/YOLOv11 算法定位车牌位置 2. 把检测到车牌输入到PaddleOCR 网络进行字符识别,整个过程一气呵成,只需训练 YOLOv8/YOLOv11 车牌检测模型即可,如果有时间也可以训练自己的 PaddleOCR 车牌字符识别模型。 3. 最后就是模型可视化与应用,

AI 编程黄金搭档:Superpowers Skills × OpenSpec 实战指南

AI 编程黄金搭档:Superpowers Skills × OpenSpec 实战指南

前言 在 AI 编程时代,开发者面临两大核心挑战:一是需求与规范的模糊性导致 AI 生成代码偏离预期,二是缺乏标准化执行流程导致代码质量参差不齐。而 Superpowers Skills 与 OpenSpec 的结合,恰好解决了这两个痛点 ——OpenSpec 负责 “做什么”,确保需求清晰、变更可追溯;Superpowers Skills 负责 “怎么做”,保证执行规范、质量可靠。两者相辅相成,共同构建了高效、可靠的 AI 编程闭环。 本文将从核心互补关系、最佳结合场景、实操工作流到复杂案例,全面讲解如何将这两款工具结合使用,让你的 AI 编程效率翻倍,代码质量更上一层楼。 一、核心互补关系:为什么它们是黄金搭档? Superpowers Skills 与 OpenSpec 并非简单叠加,而是形成了 “规范