Remote App Server 背后的 Vuepress 为带有 iframe 的页面提供 404

Vuepress behind Remote App Server give 404 for pages with iframe

我用 Vuepress, this website has an entire section for iframed Tableau 仪表板构建了一个静态网站。当我通过 Internet 公开网站时,我没有任何问题,一切正常,Tableau 仪表板显示正常。

当网站作为远程应用程序在公司防火墙后发布时,问题就开始出现了。本质上,它前面有一个身份验证层,URL 来自 https://mywebsite.mycompany.comhttps://privateapps.mycompany.com/https/mywebsite.mycompany.com

第一个问题是当它登陆主页时它会立即重定向到 Vuepress 的 404 页面,如果我然后点击刷新它会正确显示并且所有页面都可以工作除了带有 Tableau iframe 的所有页面自动重定向到 404 页面。

我认为这可能是 SSR 不匹配,所以我尝试了 vuepress-plugin-dehydrate,其中 noSSR 选项没有任何改变,但是当我应用 noScript 选项时,错误消失了仪表板页面但 iframe 不再有效,因为据我了解,此选项会删除所有 js 文件,使 iframe 变得毫无用处...

发生了某种奇怪的重定向冲突,但我不确定如何解决,我还尝试将 location 添加到我的 nginx 配置中,认为 nginx 的路由与网站,但那里也没有骰子。

 server {
     # listen on port 80 (http)
     listen 80;
     server_name _;

     root /usr/share/nginx/html;

    location / {
      try_files $uri$args $uri$args/ index.html;
    }

 }

我在远程应用程序后面的页面上也收到此警告 - 不确定是否相关。

无论如何,我已经尝试了所有我能想到的方法,但我 运行 没有想法。在这方面的任何帮助都会非常好。

所以在进行了大量的故障排除之后,我能够回答我自己的问题。修复实际上非常简单,有些人可能会说优雅。

vuepress 网站搞砸的原因是 PaloAlto,远程应用程序提供者,当服务防火墙后面的应用程序时,将 URL 更改为 https://privateapps.mycompany.com/https/mywebsite.mycompany.com 之类的东西,问题是添加 /https/mywebsite.mycompany.com 会使 vuejs 路由器感到困惑,认为这是一条需要解析的路径,而不是应用程序的基础。

所以为了解决这个问题,我在 vuepress 中使用了一个 App Level Enhancement,结果是这样的:


    export default ({
      Vue, // the version of Vue being used in the VuePress app
      options, // the options for the root Vue instance
      router, // the router instance for the app
      siteData // site metadata
    }) => {

      router.beforeResolve((to, from, next) => {

        // Any path I went redirected to the base I would add to the Array below
        const editable = ['/https/mywebsite.mycompany.com']

        let flag = editable.filter(i => to.fullPath.startsWith(i))

        if(flag.length > 0){
          const newPath = to.fullPath.replace(flag[0],'/');
          //Forcing the router to point to the base of the app
          next(newPath);
        }else {
          next();
        }

      })
    }

解决方案是使用 navigation guard router.beforeResolve 将在确认导航之前立即调用,毕竟 in-component 守卫和异步路由组件已解析。

这不一定相关,但我也修复了我的 nginx 配置,按照 this post 的建议设置如下:

    server {
      listen 80 default_server;
      listen [::]:80 default_server;

      root /your/root/path;

      index index.html;

      server_name you.server.com;

      location / {
        try_files $uri $uri/ @rewrites;
      }

      location @rewrites {
        rewrite ^(.+)$ /index.html last;
      }

      location ~* \.(?:ico|css|js|gif|jpe?g|png)$ {
        # Some basic cache-control for static files to be sent to the browser
        expires max;
        add_header Pragma public;
        add_header Cache-Control "public, must-revalidate, proxy-revalidate";
      }

    }

我希望这个 post 对其他人有用,因为这是一个非常烦人的故障排除问题。