Oracle 19c中为用户授予调用Web服务权限需配置网络ACL：先用CREATE_ACL授connect权限，再用ADD_PRIVILEGE补resolve权限（域名场景必需），接着ASSIGN_ACL精确绑定主机与端口，全程须DBA执行并COMMIT。
Oracle 19c 中给用户授予调用 Web 服务的权限，本质是配置网络 ACL（Access Control List），不是简单 GRANT 语句能解决的。直接执行 UTL_HTTP.request 或 UTL_DBWS 会报错：ORA-24247: network access denied by access control list (ACL)，说明 ACL 缺失或不匹配。
CREATE_ACL 必须指定 principal 为真实数据库用户名（区分大小写）
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL 的 principal 参数必须填数据库中已存在的、**大写形式的用户名**（除非建用户时加了双引号）。常见错误是填了小写名、角色名、或者拼错：
• 用户实际是 APP_USER，却写了 principal => 'app_user' → 失败
• 用户不存在（比如还没 CREATE USER）就去建 ACL → 报 ORA-46051
• principal 填了角色如 'CONNECT' → 不生效，ACL 只认具体用户或角色名，但角色需显式授权且该角色本身得有 EXECUTE 权限
• privilege => 'connect' 是必须的第一步，但仅此不够——如果目标地址含域名（非 IP），还必须加 resolve 权限
ADD_PRIVILEGE 补 resolve 才能解析域名
调用 Web 服务时 URL 含域名（如 https://api.example.com），Oracle 内部需 DNS 解析。若只授 connect，会卡在“无法解析主机名”，报 ORA-29273 + ORA-12545。必须追加 resolve：
• 先运行 CREATE_ACL（含 connect）
• 紧接着运行 ADD_PRIVILEGE：
BEGIN
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(
acl => 'web_service_acl.xml',
principal => 'APP_USER',
is_grant => TRUE,
privilege => 'resolve'
);
END;
• 注意：同一个 acl 文件下，connect 和 resolve 都要显式添加，不能省略任一
ASSIGN_ACL 的 host 和端口必须精确匹配请求目标
ASSIGN_ACL 的 host 参数不支持正则，只支持通配符 * 或完整域名/IP；端口范围若写宽泛（如 lower_port => 1, upper_port => 65535），虽能跑通但违反最小权限原则：
• 请求 URL 是 http://service.internal:8080/api → host => 'service.internal'，lower_port => 8080，upper_port => 8080
• 若用 HTTPS，端口通常是 443，别漏掉
• host => '*' 允许所有主机，测试可用，生产禁用
• 主机名大小写敏感：若 DNS 解析要求 Api.Example.Com，ACL 里也得写成那样（极少，但可能）
• 如果目标服务用负载均衡 VIP，ACL 应配 VIP 的 IP 或 DNS 名，而非后端真实节点
COMMIT 不是可选操作，且需 DBA 权限执行全过程
所有 DBMS_NETWORK_ACL_ADMIN 过程都是自治事务，但最终权限生效依赖 COMMIT。更关键的是：执行者必须有 EXECUTE ON DBMS_NETWORK_ACL_ADMIN，普通用户默认没有：
• 通常由 SYS 或具有 DBA 角色的用户执行整套操作
• 普通用户即使被赋了 EXECUTE，也无法创建 ACL（Oracle 限制）
• 每次执行 PL/SQL 块后必须跟 COMMIT;，否则查询 DBA_NETWORK_ACLS 看不到记录
• 验证是否生效：用授权用户连库，执行 SELECT UTL_HTTP.REQUEST('http://...') FROM DUAL;，而不是只查数据字典
ACL 配置真正容易被忽略的点在于：它不校验目标服务是否可达，只管“允许不允许发包”。所以即使 ACL 完全正确，仍可能因防火墙、DNS 不通、SSL 证书问题失败——那些属于网络层或应用层问题，和 Oracle ACL 无关。
