Vuepress behind Remote App Server give 404 for pages with iframe

Question

I buit a static website with Vuepress, this website has an entire section for iframed Tableau dashboards. When I expose the website over the internet I have no problem whatsoever everything works fine, the Tableau dashboards display like they should.

The issues start happening when the website is published behind the company's firewall as a remote app. Essentially there is an authentication layer in front of it and the URL goes from https://mywebsite.mycompany.com to https://privateapps.mycompany.com/https/mywebsite.mycompany.com

The first issue is when it lands on the home page it instantly redirects to Vuepress' 404 page, if I then hit refresh it display properly and all the pages work except for the ones with the Tableau iframe all of those pages auto redirect to the 404 page.

I thought it may be an SSR mismatch so I tried the vuepress-plugin-dehydrate for which the noSSR options changed nothing but when I applied the noScript options, the error went away on the dashboard pages but the iframe no longer worked because it is my understanding that, this option strips out all js files rendering the iframe effectively useless...

There is some sort of weird redirecting conflict happening, but I am not sure how to fix it, I also tried adding location to my nginx config thinking that the routing of nginx was conflicting with that of the site but no dice there either.

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

     root /usr/share/nginx/html;

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

 }

I also get this warning on the page when behind the remote app - not sure if it is related.

In any case I have tried everything I could think of and I am running out of ideas. Any help on this would be really nice.

Answer 1

So after a lot of troubleshooting, I was able to answer my own question. The fix is actually quite simple and some might say elegant.

The reason the vuepress site was messing up is that PaloAlto, the remote app provider when server an app behind the firewalll changes the URL to something like https://privateapps.mycompany.com/https/mywebsite.mycompany.com, the issue with that is the addition of /https/mywebsite.mycompany.com confuses the vuejs router into thinking that this is a path that needs resolving and not the base of the app.

So in order to remedy this, I utilized an App Level Enhancement in vuepress, and it went something like this:

    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();
        }

      })
    }

The solution was to use a navigation guard router.beforeResolve that will be called right before the navigation is confirmed, after all, in-component guards and async route components are resolved.

This isn't necessarily related but I fixed up my nginx config as well to be a little more robust by following this post that was suggesting setting it up as follow:

    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";
      }

    }

I hope this post will be useful to others because this was a very annoying issue to troubleshoot.