在AWS上使用噩梦JS，导出到PDF使用一个端口，而不是在另一个端口上工作

Question

我有一个导出PDF功能，在一个应用程序，电子邮件财务数据给用户。我使用我的测试站点获得了这个功能100%的工作，但当我部署到我的生产站点时，它不起作用。在prod站点上，用户通过电子邮件发送一个空白、1kb、1页的PDF文件(这在PDF查看器中是可打开的)。

下面是我如何让这个特性工作的最低要求。我使用这个指南让梦魇JS在Amazon上工作。

1. 服务器导出接收/export调用
2. 调用一个子进程，该进程使用xvfb-run创建一个可视化框架缓冲区，供噩梦JS使用。 主管(xvfb-run -a --server-args="-screen 0 1366x768x24" node ${path.join(\_\_dirname, 'export.js')} ${process.env.TYPE} ${token} ${req.user.email})
3. 在export.js过程中，噩梦JS从站点正在运行的端口加载HTTP浏览器(测试站点:端口3001，prod : 3000)。 .viewport() .goto( 1366,768) .goto( http://localhost:${process.env.PORT}/export\_summary\_1? exportToken=${exportToken} ) .wait(3000) .pdf() .end() .then( pdfBuffer ){ mailOptions.attachments ={ filename：‘financial_model.pdf.pdf’，内容:pdfBuffer} email.send(mailOptions) }
4. /export_summary_1浏览器页面进行另一个服务器调用，使用导出令牌加载和显示财务数据。然后，如上面的代码所示，梦魇将页面捕获为PDF，最后将此PDF发送给用户。

我不相信我的AWS设置是罪魁祸首，因为导出到PDF系统的相关部分都是在本地完成的，都是在AWS实例上完成的(例如，噩梦页面加载是对http://localhost:[port]/export_summary_1进行的)。

我确实有一个HTTP->HTTPS重定向，但是对于噩梦页面加载和加载页面的服务器调用来检索金融数据，我已经绕过了这一点。

尽管我不认为问题是我的AWS设置，但为了完整起见，这里是关于AWS和端口设置的说明。

• 在我的实例使用的安全组中启用了端口3000和3001。
• 负载均衡器设置
  • 端口80和443侦听器转发到‘EC2-实例-目标’，它使用端口3000将AWS实例作为注册目标。
  • 端口3001侦听器使用端口3001将AWS实例作为注册目标转发给‘EC2-devInstance- target’。

​

此外，AWS实例是“EC2-实例-目标”视图中的“不健康”注册目标(“EC2-实例-目标”用于prod站点)。这是因为，我相信，“EC2-实例-目标”目标组的端口设置为80，而注册目标的端口设置为3000。

但是，prod站点仍然工作，正如我前面所说的，这些AWS/load平衡器设置似乎不是问题源，因为导出到PDF系统包含在AWS实例中，对于所有意图和目的都是如此。

虽然，我确实计划在几个小时内解决上述问题，而此时正是我的夜晚。

此外，我还评论了恶梦页面对服务器的财务数据调用。现在，导出到PDF的加载页面上只有“hello world”文本。这个问题仍然存在。

如何使导出到PDF功能在prod站点上工作？

Answer 1

tldr; NightmareJS加载了一个空白页，该页面被导出为PDF，因为https://localhost:3000/bundle.js和https://localhost:3000/styles/style.css有子调用，它们负责所有显示的内容，无法连接(由于HTTPS是通过AWS负载均衡器实现的，因此没有设置HTTPS服务器)。

在我的问题中，我提到了我是如何认为出口到PDF处理的相关部分都是在本地完成的。实际上是这样的，但是还有更多的HTTP->HTTPS重定向正在进行。以下是HTTP->HTTPS重定向代码的外观：

app.use(function(req, res, next) {
    if(!req.secure &&
       req.get('X-Forwarded-Proto') !== 'https' &&
       // above: achieves HTTP->HTTPS redirecting using AWS load balancer and EC2 instance
       !/export_summary/.test(req.url)) {
           res.redirect('https:' + req.hostname + req.url)
    } else {
        next()
    }
})
// NOTE: all code above is commented out on test site, and uncommented for production site

下面是一个说明如何使用AWS负载均衡器和Stackoverflow页面实例实现HTTP->HTTPS重定向的Stackoverflow页面，以及上面代码中使用的内容。

当我最初将导出到PDF的特性部署到prod站点时，我收到了一个NightmareJS错误，告诉我无法到达https://localhost:3000/export_summary。因此，我插入了!/export_summary/.test(req.url)条件，以便NightmareJS对export_summary页面的HTTP调用不会被重定向到HTTPS调用。

上面的代码块也是针对加载export_summary页面的NightmareJS的子调用执行的。因此，对http://localhost:3000/bundle.js和http://localhost:3000/styles/style.css的两个主要子调用被重定向到它们的HTTPS对应项。(注意: bundle.js调用是为/export_summary服务的HTML中的<script src='bundle.js'></script>。

由于在AWS实例上没有实际设置HTTPS服务器，这些子调用无法连接(客户端会将其报告为“拒绝连接”错误消息)。该应用程序的HTTPS是通过AWS负载均衡器实现的。

这两个资源负责整个应用程序的显示内容。因此，没有它们，加载的页面是白色和空白的，如导出的PDF所示。

另外，正如上面代码块中的注释所提到的，HTTP->HTTPS重定向代码在测试站点上被注释掉了。这解释了我是如何在测试站点上看到预期的特性工作的，因为麻烦的中间件不是处理的一部分。

解决方案

我更新了绕过HTTP->HTTPS重定向的条件，以包括相关的子调用：

!/(export_summary)|(exportPrivate)|(bundle\.js)|(style\.css)|(\.png)|(\.ttf)|(\.woff)/.test(req.url))

注: PNG、TTF和WOFF资源调用也需要绕过，因为它们是完整的、完善的PDF所必需的。

最后，我看不出这里存在安全风险，尽管我当然可以想象会有一些安全改进。

• 在bundle.js、style.css和图像/字体文件中不保存机密数据。
• 对于/export_summary调用，服务器使用一个index.html文件进行响应，该文件用于部署应用程序(那里也没有机密数据)。
• 绕过对包含'exportPrivate‘子字符串的端点的调用，NightmareJS的调用将加载被导出到PDF的用户数据。不存在这样的情况，即该调用将在internet上使用，因为该调用是允许跨HTTP的。它只允许在服务器上使用无头客户端浏览器(如NightmareJS )。

欢迎对改进解决方案的安全方面提出任何建议。