对iframe嵌套的页面进行同域代理时需要注意哪些问题

风屿
144 阅读6分钟

A项目的publicPath设置为/，A项目被B项目进行iframe嵌套后进行同域代理，出现js静态资源路径问题

image.png

出现该问题的原因可能如下：

A项目的publicPath设置为/时，所有静态资源的加载路径是绝对路径。当它被B项目的iframe嵌套时，如果B项目不是位于根路径，或者通过代理存在路径问题，静态资源路径会错误地指向B项目的根目录。可以将publicPath设置为相对路径（如./）或调整iframe及B项目的路径配置，以确保资源正确加载。但更多的情况下，A项目的publicPath不会根据某项目的要求来设置值。

这里我们可以先回顾一下publicPath

publicPath

/与./的区别

  1. / (绝对路径) :

    • 表示项目的根目录，即基于服务器根路径来加载静态资源。
    • 使用这种配置时，项目中的所有静态资源都将从根路径加载。适用于应用程序部署在服务器的根目录下的情况，如 https://www.example.com/。
    • 示例：资源路径将会是https://www.example.com/js/app.js。

适用场景:

  • 当应用程序托管在服务器的根目录时使用。例如，部署在https://www.example.com/。

  1. ./ (相对路径) :

    • 表示相对于当前 HTML 文件的路径，适用于不同的目录或子路径部署。
    • 这种配置使得资源路径相对于当前页面的路径动态加载，常见于将应用程序部署在子目录下或以文件协议打开静态页面的情况。
    • 示例：资源路径将会是https://www.example.com/some/subfolder/js/app.js。

适用场景:

  • 当应用程序部署在子目录中时使用，例如 https://www.example.com/subfolder/。
  • 当项目需要支持本地打开时，如直接用文件协议(file://)打开静态 HTML 文件时，避免资源加载错误。

总结：

  • /：资源路径是绝对路径，适合根目录部署。
  • ./：资源路径是相对路径，适合子目录或本地文件打开的情况。

解决方案：

  1. 调整A项目的publicPath：

    • 将A项目的publicPath改为相对路径，例如./，这样静态资源将根据HTML页面的实际位置动态解析，无论是否通过iframe嵌套，资源路径都能正确解析。

  2. 使用子路径作为publicPath：

    • 如果A项目部署在B项目的某个子路径下（例如https://www.example.com/B/A/），可以将A项目的publicPath设置为/B/A/，确保静态资源加载时使用正确的路径。
    • 这样即使通过iframe嵌套，浏览器也会将静态资源请求定向到/A/下。

  3. B项目设置反向代理（openResty，具体看如下方案） ：

    • 如果确实需要通过同域代理，B项目可以配置反向代理规则，重写所有指向A项目根目录的请求到对应的代理路径上，以确保静态资源正确加载。

使用openResty进行解决

OpenResty 可以帮助解决这种静态资源路径问题。OpenResty 是一个基于 Nginx 的高性能 Web 平台，可以通过配置反向代理、重写路径和其他功能来解决静态资源加载路径的问题。以下是如何使用 OpenResty 来解决这个问题的思路和配置方案：

方案 1: 使用 OpenResty 配置反向代理来重写资源路径

你可以通过 OpenResty 的反向代理功能，将所有指向 A 项目的静态资源请求代理到正确的路径上。具体步骤如下：

  1. 假设部署路径：

    • A 项目被部署在 https://www.example.com/A/。
    • B 项目嵌套 A 项目时，通过 iframe 加载 A 项目。

  2. 问题重现：

    • A 项目的 publicPath 设置为 /，因此 A 项目的静态资源路径会是 /js/app.js。当 A 项目通过 iframe 嵌套在 B 项目中时，静态资源路径会被解析为 https://www.example.com/js/app.js，而不是 https://www.example.com/A/js/app.js，从而导致资源加载错误。

  3. OpenResty 配置反向代理： 通过 OpenResty 配置，将所有指向 /js/、/css/ 等静态资源的请求重写为 /A/js/ 或 /A/css/。

这里是一个简单的配置示例：

server {
    listen 80;
    server_name www.example.com;

    # 配置B项目
    location /B/ {
        proxy_pass http://backend_b;  # 代理到 B 项目服务器或静态资源路径
    }

    # 配置A项目的反向代理
    location /A/ {
        proxy_pass http://backend_a;  # 代理到 A 项目的服务器
        proxy_set_header Host $host;  # 保持 Host 头的一致性
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # 针对A项目的静态资源进行反向代理
    location /js/ {
        rewrite ^/js/(.*)$ /A/js/$1 break;  # 将 /js/ 请求重写为 /A/js/
        proxy_pass http://backend_a;
    }

    location /css/ {
        rewrite ^/css/(.*)$ /A/css/$1 break;  # 将 /css/ 请求重写为 /A/css/
        proxy_pass http://backend_a;
    }

    # 其他可能的静态资源路径
    location /img/ {
        rewrite ^/img/(.*)$ /A/img/$1 break;
        proxy_pass http://backend_a;
    }

    location /fonts/ {
        rewrite ^/fonts/(.*)$ /A/fonts/$1 break;
        proxy_pass http://backend_a;
    }

    # 如果A项目还使用其他资源类型，比如 API 接口等，也可以在这里进行代理
}

方案 2: 利用 sub_filter 模块动态替换 HTML 中的路径

如果你不想修改 A 项目的代码，也可以利用 OpenResty 的 sub_filter 模块在返回给客户端的 HTML 中动态替换路径，让路径指向正确的静态资源位置。

  1. 场景： A 项目的 HTML 文件中，静态资源路径为 /js/app.js，你希望通过 OpenResty 把它替换为 /A/js/app.js。
  2. OpenResty 配置 sub_filter：
server {
    listen 80;
    server_name www.example.com;

    location /A/ {
        proxy_pass http://backend_a;
        sub_filter '/js/' '/A/js/';
        sub_filter '/css/' '/A/css/';
        sub_filter_once off;  # 应用到整个响应中
    }

    location /B/ {
        proxy_pass http://backend_b;
    }
}

在这个配置中，sub_filter 模块会将 HTML 响应中的所有 /js/ 替换为 /A/js/，从而确保静态资源的路径正确。

方案 3: 使用 OpenResty 设置 base 标签

如果你有控制 A 项目的 HTML 文件，可以在 OpenResty 中动态添加 <base> 标签，显式指定静态资源的加载基路径。

  1. 配置示例：

你可以使用 OpenResty 的 sub_filter 模块在 HTML 文件的 <head> 部分动态插入 <base> 标签：

server {
    listen 80;
    server_name www.example.com;

    location /A/ {
        proxy_pass http://backend_a;
        sub_filter '<head>' '<head><base href="/A/">';
        sub_filter_once on;
    }

    location /B/ {
        proxy_pass http://backend_b;
    }
}

这样会自动在 HTML 的 <head> 部分插入 <base href="/A/">，从而确保所有相对路径都基于 /A/，即使在 iframe 中加载时也能正确解析静态资源。

方案 4: 修改 OpenResty 的 location 根路径匹配

如果你的静态资源路径问题主要集中在根路径解析上，可以使用 OpenResty 修改 location 的根路径映射，将所有请求 / 的资源转发到 /A/ 下。

server {
    listen 80;
    server_name www.example.com;

    # 将根路径的所有请求都转发到 /A/ 下
    location / {
        proxy_pass http://backend_a;  # A 项目的服务器
        rewrite ^/(.*)$ /A/$1 break;  # 重写路径到 /A/
    }

    # 其他路径的请求可以正常处理
    location /B/ {
        proxy_pass http://backend_b;
    }
}

结论：

通过 OpenResty，你可以通过多种方式解决 A 项目在 iframe 中静态资源路径解析的问题。最常用的解决方法包括：

  • 配置反向代理并重写资源路径。
  • 动态替换 HTML 中的路径。
  • 插入 <base> 标签来显式指定资源路径。
avatar
文章
阅读
粉丝