【问题标题】:Mod_Proxy doesn't show OpenRefine App properlyMod_Proxy 未正确显示 OpenRefine 应用程序
【发布时间】:2017-03-23 09:07:23
【问题描述】:

我正在运行 OpenRefine(由 jetty 托管的网络应用程序):

http://127.0.0.1:3333

看起来像这样:

一切都很完美。

现在我想通过 Apache2 进行隧道传输(出于安全和重命名原因),所以我更改了我的 http.conf 文件并像这样修改它:

ProxyPass /refine http://127.0.0.1:3333
ProxyPassReverse /refine http://127.0.0.1:3333

现在,如果我尝试通过代理打开页面,这就是我所看到的:

所有动态内容似乎都无法正常工作。我该如何解决这个问题?

注意事项:

  • 我确保 mod_proxy 已更新并正常工作。使用 Tomcat 中的其他 web 应用进行了测试。

【问题讨论】:

    标签: mod-proxy openrefine


    【解决方案1】:

    可以在不使用虚拟主机的情况下将 mod_proxy 与 OpenRefine 一起使用。

    我今天需要做同样的事情。我有一个 SSL 门户,用户必须通过该门户使用一些复杂的 PKI 和 LDAP 跟踪进行身份验证,并且我需要 OpenRefine 托管在它后面,因为它可以访问一些数据。在这个线程和其他地方给出的这个问题的答案根本是不可接受的,所以我查看了预期修补此行为的源代码——但我不必这样做!

    我注意到因为 OpenRefine 用完了一个 WEB-INF 目录,它可能被构建为一个典型的 java web 应用程序。果然,当我寻找如何在服务器上设置上下文时,我在 Refine.java 中找到了这个:

    final String contextPath = Configurations.get("refine.context_path","/");

    所以这就是你要做的:

    注意:StackOverflow 不允许我编写看起来像 URL 的东西,因为我在这里没有任何声誉。因此,当您阅读 http:\ 时,这实际上意味着 http://。

    1) 在refine.ini 中,确保JAVA_OPTIONS 包含“-Drefine.context_path=/refine”。 (不言而喻,您将refine.host 更改为0.0.0.0 而不是127.0.0.1,并且还设置了refine.headless=true。)现在重新启动OpenRefine 时,您将在http:\your.refine 访问它.server:3333/refine (显然将您的服务器主机名放在该 url 中)。

    2) 现在,举个简单的例子,我们将 https:\your.apache.server/refine 代理到 http:\your.refine.server:3333/refine 。

    在您的一个 httpd 配置文件(可能在 /etc/httpd/conf.d 中创建一个 openrefine.conf)中,在启用 mod_proxy 后添加以下行:

    ProxyPass /refine http:\\your.refine.server:3333/refine
    ProxyPassReverse /refine http:\\your.refine.server:3333/refine
    

    这里的区别在于 OpenRefine 被排除在全局上下文之外,因此可以代理应用程序的根。 OpenRefine 根据上下文的设置方式使用绝对路径请求资源。因此,如果您不这样做,OpenRefine 将生成位于您的代理位置之外的 javascript 文件,正如该线程中的其他人之前所经历的那样,

    在现实生活中,您可能希望 mod_proxy 在多个 OpenRefine 实例上使用负载平衡器,并且您可能希望设置一些关于允许哪些用户使用此代理隧道的逻辑。

    希望这对其他人有帮助!

    我还建议您查看 Refine.java 中未记录的 Refine 服务器属性。

    【讨论】:

      【解决方案2】:

      您将应用位置从 http://your.server:3333/ 更改为 http://your.server/refine

      您可以看到,例如 href="/resource.css" 的链接将不再有效,因为该资源现已移至 "/refine/resource.css"。我认为,如果您深入研究 HTML 源代码,您会发现许多带有绝对路径的链接。

      此配置将破坏任何绝对路径引用。解决此问题的复杂方法称为 URL 重写,并且有深入的教程介绍了如何使用 URL 重写设置 Mod-Proxy 和 Reverse。解释复杂,容易出错;而是添加一个 VirtualHost,这样绝对路径链接就不需要重写了。

      <VirtualHost *>
          ServerName refine
      
          ProxyRequests Off
          <Proxy *>
              Order deny,allow
              Allow from all
          </Proxy>
      
          ProxyPass / http://127.0.0.1:3333/
          ProxyPassReverse / http://127.0.0.1:3333/
          <Location />
              Order allow,deny
              Allow from all
          </Location>
      </VirtualHost>
      

      您不太可能找到任何指向localhost:3333 的绝对链接,因此这可能对您有用。更改您的/etc/hosts,以便refine 解析为127.0.0.1,您将成为黄金。您现在可以毫无问题地使用来自 http://refine/ 的优化。

      127.0.0.1    localhost refine
      

      如果您尝试启用来自外部主机的访问,稍微复杂一点的设置将涉及新的 DNS 记录,从这里应该很容易想象。

      【讨论】:

      • 这解决了本地的问题,但我想从外部主机访问。我真的不认为 DNS 记录是一种解决方案,我的机器已经在端口 80 和 8089 上运行了几个服务,这会很混乱。但现在我知道什么是失败的(绝对路径),以及如何处理它(mod rewrite)。谢谢
      • VirtualHost的要点是可以在80端口上运行多个服务,让Apache根据请求细节来处理路由。每个服务都有自己的主机名,服务器根据您提供的主机名决定将您的请求传递给哪个服务。如果您希望您的服务可以从远程安全地使用,请使用 https 并将身份验证添加到 VirtualHost。我有几十个服务在防火墙后面的各种主机上的各种端口上侦听,一台 Apache 服务器位于它们前面,它们都基于 VirtualHost 管理外部访问者的访问。
      • 同时设置一个默认的虚拟主机。如果您使用的是 Debian 或 Ubuntu 系统,请查看 /etc/apache2/sites-available 和 sites-enabled
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-08-06
      • 1970-01-01
      • 2015-12-23
      • 1970-01-01
      • 1970-01-01
      • 2013-02-10
      相关资源
      最近更新 更多