Vuepress за удаленным сервером приложений дает 404 для страниц с iframe

Я создаю статический веб-сайт с помощью Vuepress, на этом веб-сайте есть целый раздел для iframed Tableau. Когда я открываю веб-сайт через Интернет, у меня нет проблем, все работает нормально, панели инструментов Tableau отображаются так, как должны.

Проблемы начинаются, когда веб-сайт публикуется за брандмауэром компании как удаленное приложение. По сути, перед ним находится уровень аутентификации, и URL-адрес идет от https://mywebsite.mycompany.com до https://privateapps.mycompany.com/https/mywebsite.mycompany.com.

Первая проблема заключается в том, что когда он попадает на домашнюю страницу, он мгновенно перенаправляется на страницу 404 Vuepress, если я затем нажимаю обновить, она отображается правильно, и все страницы работают, за исключением тех, у которых есть iframe Tableau, все эти страницы автоматически перенаправляются на 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;
    }

 }

Я также получаю это предупреждение на странице, когда за удаленным приложением - не уверен, связано ли оно.

введите описание изображения здесь

В любом случае я перепробовал все, что мог придумать, и у меня заканчиваются идеи. Любая помощь по этому поводу была бы очень хороша.


javascript vue.js vue-router remote-access vuepress
person Tekill    schedule 05.06.2019    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Итак, после долгого поиска и устранения неисправностей я смог ответить на свой вопрос. Исправление на самом деле довольно простое и некоторые могут сказать элегантное.

Причина, по которой сайт vuepress не работает, заключается в том, что PaloAlto, поставщик удаленных приложений, когда сервер приложения, находящегося за firewalll, изменяет URL-адрес на что-то вроде https://privateapps.mycompany.com/https/mywebsite.mycompany.com, проблема в том, что добавление /https/mywebsite.mycompany.com сбивает с толку маршрутизатор vuejs, заставляя его думать, что это путь, который требует разрешения, а не основа приложения.

Поэтому, чтобы исправить это, я использовал уровень приложения. Улучшение в vuepress, и оно выглядело примерно так:


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

      })
    }

Решением было использовать навигационную защиту. router.beforeResolve, который будет вызываться прямо перед подтверждением навигации, после того, как будут разрешены встроенные средства защиты и компоненты асинхронного маршрута.

Это не обязательно связано, но я исправил свою конфигурацию nginx, чтобы сделать ее немного более надежной, выполнив это сообщение, в котором предлагалось настроить его следующим образом:

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

    }

Я надеюсь, что этот пост будет полезен другим, потому что это очень неприятная проблема для устранения неполадок.

person Tekill    schedule 20.06.2019