Security jsp指的是PDF流式servlet的安全问题

在我们的防火墙后面的某个地方，有一台装满PDF的服务器。PDF包含私人信息，因此我需要限制对PDF的访问。公众可以登录我们的网站并申请他们的PDF

我们的软件最近投入生产。我们正在将它们重定向到PDF服务器的URL。这失败了，因为公众无法访问我们的PDF服务器。这是一件好事，尽管我更愿意在发射前证明这一点

我编写了一个PDF servlet，将PDF流式传输到用户的浏览器。我们的JSP使用

HTML标记引用servlet。原型运行良好

我不想让世界直接访问servlet，因为有人可能会摆弄URL，不适当地抓取PDF

现在，最后，我的问题。如果servlet位于防火墙后面，JSP能否成功引用PDF servlet？PDF是否会在线显示？用户会得到一个“保存”对话框吗

如果servlet位于防火墙后面，JSP能否成功引用PDF servlet

PDF请求只算作一个单独的HTTP请求。servlet不知道它是在防火墙后面还是被JSP调用。最安全的方法是检查HTTP头或HTTP会话中是否存在用户凭据

PDF是否会在线显示？用户会得到一个“保存”对话框吗

---

这取决于是否存在

内容配置
标题和/或浏览器的配置。如果标题不存在或显式设置为
inline
，并且浏览器支持
content-type
标题中指定的内容类型，则它将以内联方式显示，否则它将询问如何处理：在某个应用程序中打开或保存它。如果标题设置为附件，则取决于浏览器配置。默认情况下，它会弹出一个“另存为”对话框，但用户可能已将浏览器配置为在某些外部应用程序中立即打开它。
噢，你真让我心神不宁。握手的拳头交易是，我第一次做这些它流图像之一。现在它卡在我的脑子里了。最安全的方法…你是对的。我继承了这个。登录安全性是。。。独一无二。我提到过应用程序都是jsp，根本没有servlet吗？无论如何，我想一个更好的问题是，
何时渲染？如果它是由用户的浏览器呈现的，那么我就注定了——PDF servlet必须是全局可访问的。当我输入这个时，我有点知道答案。好吧，老板对此没有意见，所以我想我在这里采取低调的态度，努力实现真正的身份验证。HTML是在客户端呈现的。webbrowser负责呈现HTML并对HTML中的链接资源发出另一个HTTP请求，如
，
，
，
，
，等等。换句话说，你注定要失败。并不是JSP以某种方式将所有内容加载并神奇地压缩到单个HTTP响应中：）