jsp防止直接通过url访问没有权限的页面

Posted 2023-05-12

jsp防止直接通过url访问是通过过滤器实现的。
过滤器内容：
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException
HttpServletRequest req = (HttpServletRequest) request;
HttpServletResponse resp = (HttpServletResponse) response;
String conString = "";
conString = req.getHeader("REFERER");//获取父url--如果不是直接输入的话就是先前的访问过来的页面，要是用户输入了，这个父url是不存在的
if("".equals(conString) || null==conString) //判断如果上一个目录为空的话，说明是用户直接输入url访问的
String servletPath = req.getServletPath();//当前请求url，去掉几个可以直接访问的页面
if(servletPath.contains("index.jsp") || servletPath.contains("admin/login.jsp")) //跳过index.jsp和登陆Login.jsp
chain.doFilter(request, response);
else
resp.sendRedirect("/ejuornal/index.jsp");//跳回首页

else
chain.doFilter(request, response);


过滤器配置：
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5">
<display-name></display-name>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
<filter>
<filter-name>FilterPages</filter-name>
<filter-class>com.ejuornal.filter.FilterPages</filter-class>
</filter>
<filter-mapping>
<filter-name>FilterPages</filter-name>
<url-pattern>*.jsp</url-pattern>
</filter-mapping>
</web-app> 参考技术A

你可以用request获得之前的页面路径：Request.getHeader("Referer");然后你可以判断一下，这个是字符串类型的。


如果是需要登录的，你可以从session中获取登录信息，然后判断

你可以通过上一个页面传参，本页面判断，如果不匹配就处理，参数可以放在session当中或者使用request.setAttribute();这个方法，不要URL传参

参考技术B 设置相关权限判断，并且书写在访问页面的开始。来防止用户访问没有权限的页面。
如果你有其他问题，可以前往房子SEO优化论坛网站建设栏目提问。 参考技术C 可以设置过滤器！重定向用户访问的无权限页面！

防止使用浏览器 url 直接访问图像

【中文标题】防止使用浏览器 url 直接访问图像

【英文标题】：Prevent direct access to images using the browser url

【发布时间】：2012-11-19 11:40:47

【问题描述】：

我有一个名为 - Images 的文件夹。此文件夹包含用户个人资料图片。现在用户可以随时通过将图像 URL 复制到他的浏览器来查看他的图像。这样他也可以看到其他用户的个人资料照片。我想要实现的是 - 用户应该只能通过我网站上的 PHP 页面查看他的个人资料图片。如果用户直接放图片 URL，就不应该显示。

我尝试使用 .htaccess 来实现这一点。这就是我在 .htaccess 文件中的内容：

RewriteEngine On
RewriteCond %HTTP_REFERER !^$
RewriteCond %HTTP_REFERER !^http://(www\.)?mysite.com/
RewriteRule \.(gif|jpg)$ http://www.mysite.com/errorpost.jpg [R,L]

我是 .htaccess 的新手。如果有办法实现这一点，请提供帮助。

提前致谢。

【问题讨论】：

上面我用的方法不行。输入图像 url 时，它仍然显示图像。

看看这对你有没有帮助：***.com/questions/9282124/…

你想解决什么问题。是否要阻止人们查看个人资料的个人资料图片，他们不允许查看？

@Gerben .. 假设我正在查看我的个人资料。通过查看源代码，我可以看到我的个人资料图片的图像位置。然后我将该网址粘贴到地址栏并打开图像。现在我希望用户不能以这种方式直接访问图像。是否可以限制用户直接查看图像。应该允许他仅使用我创建的作为个人资料页面的 PHP 页面查看图像。这样他就无法猜测其他用户的网址，也无法看到他们的图片。

为个人资料图像生成伪随机文件名应该可以解决这个问题。例如使用配置文件 ID 的 md5 作为图像文件名。

【参考方案1】：

我也有同样的问题。目前我找到了两种方法：

1) base64_encode() + ajax + js/jquery

将 base64_encode() 编码的每个图像存储在二进制文件或数据库 OUTSIDE www 文件夹中。 使用 ajax 获取该数据。它应该返回“data:image/jpeg;base64,$enc_imgbinary” 使用 js/jquery 将 'img' 属性的 'src' 替换为返回的结果

优点

无法通过直接链接访问图片

缺点

我没有找到类似的视频解决方案。 应事先（或首次使用）对图像进行编码，以尽量减少服务器 CPU 使用率。 编码图像占用的磁盘空间增加了大约 30% => 1.3 倍的磁盘空间 如果您想在服务器上保留原始图像 => 2.3 倍磁盘空间。 大约 30% 的数据将通过网络发送

2) 长随机名称（+符号链接）

A) 使用长随机名称将图像存储在 www 文件夹中 B）将图像存储在 www 文件夹之外，并带有指向 www 文件夹的符号链接。 （www 以外的图片也可以作为您的桌面图片备份）

注释：

文件夹还必须包含随机符号 使用'.'在任何文件夹或文件名之前 => 以防万一，以防止在未配置的 apache 上显示文件夹内容 在情况 B) 中配置 apache 以遵循符号链接（将 FlowSymlinks 添加到 httpd.conf） 配置 apache 以防止文件夹内容列表（从 httpd.conf 中删除索引）

图像层次结构示例：

万维网 .media_jmdue7jed .user1_hash_!sdfsewewfsdfsds .album1_name_!jfie8e7y77667fef .photo1_name_!kjio9i890v8fsd978fyreshf .photo2_name_!09098dfuujdsif87s7ysdffd ... .album2_name_!ghhyuflp!huidfjh .photo1_name_!feojihudhufuuhfrufhi8484 .photo2_name_!2344gfdgfdgdfefedw232sdg ... .user1_hash_!j333re89dsfdsf ...

优点：

也可以用于视频 您仍然可以通过使用长随机名称创建指向 www 文件夹的符号链接，将原始图像与原始名称保留在 www 文件夹之外。甚至对每个用户都不同。 图片可以在您的服务器之外使用（在论坛中，快速发送直接链接给您的朋友或类似的）

缺点

必须事先（或即时）创建符号链接 可以通过直接链接访问图像 但是几乎不可能猜到它 您也可以定期更改符号链接随机名称或更改图像权限（我怀疑 google+ 会这样做） map original-name → long-random-name 应该存储在 db（或 sidecard/meta 文件）中 （如果您通过编码/解码或组合 original-name + long-random-name 将 original-name 保留在 long-random-name 中，则可以绕过）

=======================================

我已经实现了案例 1)，它对我来说很好，但是我没有为 HTML5 视频找到类似的解决方案。

案例 2) 似乎更灵活。但是我仍然不确定安全性。 如果有人发现安全漏洞，请告诉我。