使用 Tomcat 应用程序保护 HttpServer 上的内容 - 有什么想法吗？
我们在 Tomcat 上有一个 Web 应用程序。该应用程序从专用 Apache HTTP 服务器访问内容（机密）。我们不希望未经授权的用户访问此内容。即只有通过 WebApp（在 Tomcat 上）进行身份验证的用户才能访问 HttpServer 内容。 （我们使用 HTTPS 来保护网络，但如果有人获取内容的直接 httpserver url，他们可能会下载内容）。
我们正在考虑在 Tomcat 上的同一个 Web 应用程序中托管内容。有什么想法吗？
We have a Web Application on Tomcat. The App accesses content(confidential) from dedicated Apache HTTPServers. We do not want un-authorized users accessing this content. i.e. Only users authenticated through WebApp(on Tomcat) can access HttpServer content.
(We are using HTTPS to secure the network, but if someone gets the direct httpserver url for content they may download content).
We are thinking of hosting content in side the same webapp on Tomcat. Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
执行此操作的简单/惰性方法是强制每次访问 Apache 服务器时的 HTTP Referrer 都是 Tomcat 服务器的地址。相关页面： http://www.htaccess-guide.com/deny -visitors-by-referrer/
但是，如果黑客发现这是您的保护方案，那么欺骗 HTTP 引荐来源网址是相当简单的。
两种更复杂但安全的方法，按工作顺序排列：
在 Tomcat 服务器上编写 JSP 页面或其他内容来验证用户是否已登录，然后通过 HTTP 从 Apache 获取数据，然后将数据输出回最终用户。通过这样做，您可以有效地编写自己的反向代理。然后将 Apache 服务器锁定为仅向 Tomcat 服务器的 IP 地址（以及您希望允许的任何其他授权/内部 IP）提供页面。优点：仍然很快。缺点：您使用 tomcat 资源来显示其他服务器上的每个页面，它可能会引入可扩展性问题，特别是如果 apache 服务器提供大量字节（例如，如果 apache 提供 500 meg 文件，是否会耗尽资源）你的 tomcat 脚本的内存？这取决于你编码和测试 JSP 页面的能力！）。如果页面很小，可能不是问题。
在 Apache 和 Tomcat 之间实现某种单点登录。这可以是基于 cookie 的或者更奇特的东西（比如使用跟踪会话的后端身份验证服务器）。通过这种方式，Apache 就会知道请求 https:// 页面的用户已通过正确的身份验证，否则会拒绝该请求。优点：完全可扩展。缺点：较难设置，许多解决方案都是商业/付费产品。
The easy/lazy way to do this is to enforce that the HTTP Referrer on each hit to the Apache servers is the addrress of your Tomcat server. A page on that: http://www.htaccess-guide.com/deny-visitors-by-referrer/
However, it's fairly trivial for a hacker to spoof the HTTP referrer if they figure out that's your protection scheme.
Two more complicated but secure methods, in order of effort:
Write a JSP page or something on the Tomcat server that verifies the user is logged in, then fetches the data off Apache by HTTP, and then outputs the data back to the end user. You are effectively writing your own reverse proxy by doing this. Then have the Apache server locked down to only serve pages to the Tomcat server's IP address(es) (and any other authorzied/internal IPs you wish to allow). Pros: still pretty quick to do. Cons: you're using tomcat resources to display each page off the other server, it can introduce scalability issues, especially if the apache servers serve up large numbers of bytes (for instance, if apache serves up a 500 meg file, will that exhaust your tomcat script's memory? That depends how well you code and test your JSP page! Beware!). If the pages are tiny, it's probably not an issue.
Implement some kind of Single Sign On between Apache and Tomcat. This could be cookie based or something fancier still (like with a backend authentication server tracking the sessions). In this way Apache would know that the user requesting the https:// page was properly authenticated and would deny the request otherwise. Pros: Completely scalable. Cons: harder to set up, many of the solutions out there are commercial/pay products.