Vuepress за Remote App Server дают 404 для страниц с iframe - PullRequest
Новая
       37

Vuepress за Remote App Server дают 404 для страниц с iframe

0 голосов
/ 05 июня 2019

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

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

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

 }

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

enter image description here

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

1 Ответ

1 голос
/ 20 июня 2019

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

Причина, по которой сайт 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";
      }

    }

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

...