referer

发布时间:2015-05-25 来源: 在线翻译

第一篇:referer

6.4.10 利用Referer请求头阻止“盗链” 有一些站点自己没有提供下载空间,但是为了吸引人气和提高站点的访问量,他们也提供了各种软件的下载页面,并让下载的超链接指向其他站点上的资源。另外一些真正提供了下载空间的站点为了防止这种“盗链”,需要检查请求的来路,只接受本站内的页面链接进来的下载请求,而阻止其他站点的页面链接进来的下载请求。要实现这样的功能,就需要检查请求消息的referer头字段是否与本站匹配。 :动手体验:利用Referer请求头阻止“盗链” (1)按例程6-3编写一个名为DownManagerServlet的Servlet程序,这个Servlet程序负责提供下载内容,但它要求下载请求必须通过本站的下载页面链接进来,否则将请求转发给本站的下载说明页。 例程6-3 DownManagerServlet.java import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class DownManagerServlet extends HttpServlet { public void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html ;charset=gb2312"); PrintWriter out = response.getWriter(); String referrer = request.getHeader("referer"); String sitePart = "http://" + request.getServerName(); if(referrer!=null && referrer.startsWith(sitePart)) { //处理正当的下载请求,这里只进行示意 out.println("dealing download ..."); } else { //非法下载请求跳转到本站的下载说明页 RequestDispatcher rd = request.getRequestDispatcher("/down.html"); rd.forward(request,response); } } } 编译DownManagerServlet.java文件,确保编译后生成的class文件存放在了<tomcat的安装目录>\webapps\it315\WEB-INF\classes目录中。 (2)在<tomcat的安装目录>\webapps\it315\WEB-INF\web.xml文件中注册该Servlet,并设置其映射URL。在web.xml文件中的相应位置处增加如下两段内容: <servlet> <servlet-name>DownManagerServlet</servlet-name> <servlet-class>DownManagerServlet</servlet-class> </servlet> …… <servlet-mapping> <servlet-name>DownManagerServlet</servlet-name> <url-pattern>/servlet/DownManagerServlet</url-pattern> </servlet-mapping> 保存web.xml文件后,重新启动Tomcat。 (3)在<tomcat的安装目录>\webapps\it315目录中编写一个名称为down.html的网页文件,内容如下: <base href="http://localhost:8080/it315/down.html" /> <a href="servlet/DownManagerServlet">down</a> 接着在浏览器地址栏中输入如下地址: http://localhost:8080/it315/servlet/DownManagerServlet 由于这是直接在浏览器地址栏中输入的访问地址,请求消息中不含Referer请求头,DownManagerServlet将down.html页面转发给浏览器,浏览器中显示的结果如图6.4所示。 图6.4 图6.5 单击图6.4中的超链接再次访问DownManagerServlet,由于这时的请求消息中包含有Referer请求头且其值与DownManagerServlet位于同一WEB站点,DownManagerServlet接受下载请求,浏览器中显示的结果如图6.5所示。

第一篇:referer

HTTP Referer 什么是 HTTP Referer 简言作文之, HTTP Referer 是 header 的一部分, 当浏览器向 web 服务器发送请求的时候, 一般会带上 Referer,告诉服务器我是从哪个页面链接过来的,服务器 籍此可以获得一些 信息用于处理。比如从我主页上链接到一个朋友那里,他的服务器就能够从 HTTP Referer 中统计出每天有多少用户点击我主页上的链接访问他的网站。

Referer 其实应该是英文单词 Referrer, 不过拼错的人太多了, 所以编写标准的人也就 将错就错了。 我的问题 我刚刚把 feed 阅读器改变为 Gregarius ,但他不像我以前用的 liferea,访问新浪博客的时 候,无法显示其中的图片,提示“此图片仅限于新浪博客用户交流与沟通”,我知道,这就是 HTTP Referer 导致的。

由于我上网客户端配置的特殊性 ,首先怀疑是 squid 的问题,但通过实验排除了,不过同 时发现了一个 Squid 和 Tor、Privoxy 协同使用的隐私泄露问题 ,留待以后研究。 Gregarius 能处理这个问题么? 能处理这个问题么? 答案是否定的 ,因为 Gregarius 只是负责输出 html 代码,而对图像的访问是有客户端浏览 器向服务器请求的。

不过,安装个 firefox 扩展也许能解决问题,文中推荐的”Send Referrer”我没有找到,但发 现另外一个可用的:”RefControl “,可以根据访问网站的不同,控制使用不同的 Referer。

但是我不喜欢用 Firefox 扩展来解决问题,因为我觉得他效率太低,所以我用更好的方式 ——Privoxy。 Privoxy 真棒 在 Privoxy 的 default.action 中添加两行

{+hide-referrer{forge}} .album.sina.com.cn 这样 Gregarius 中新浪博客的图片就出来了吧?+hide-referrer 是 Privoxy 的一个过滤 器,设置访问时对 HTTP Referer 的处理方式,后面的 forge 代表用访问地址当作 Refere 的,还可以换成 block ,代表取消 Referer,或者直接把需要用的 Referer 网址写在这里。

用 Privoxy 比用 Firefox 简单的多,赶紧换 吧。 From https to http 我还发现, 从一个 https 页面上的链接访问到一个非加密的 http 页面的时候, http 页面上 在 是检查不到 HTTP Referer 的,比如当我点击自己的 https 页面下面的 w3c xhtml 验证图标 (网址为 http://validator.w3.org/check?uri=referer ),从来都无法完成校验,提示

No Referer header found! 原来,在 http 协议的 rfc 文档 中有定义

15.1.3 Encoding Sensitive Information in URI's ... Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. 这样是出于安全的考虑,访问非加密页时,如果来源是加密页,客户端不发送 Referer,IE 一直都是这样实现的,Firefox 浏览器也不例外 。但这并不影响从加密页到加密页的访问。 Firefox 中关于 Referer 的设置 都在里,有两个键值: ? network.http.sendRefererHeader (default=2) 设置 Referer 的发送方式, 为完全不发 0 送, 为只在点击链接时发送, 1 在访问页面中的图像什么的时候不发送, 为始终发送。

2 参见 Privacy Tip #3

Block Referer Headers in Firefox ? network.http.sendSecureXSiteReferrer (default=true) 设置从一个加密页访问到另外 一个加密页的时候是否发送 Referer,true 为发送,false 为不发送。 利用 Referer 防止图片盗链 虽然 Referer 并不可靠,但用来防止图片盗链还是足够的,毕竟不是每个人都会修改客户端 的配置。实现一般都是通过 apache 的配置文件,首先设置允许访问的地址,标记下来

# 只允许来自 domain.com 的访问,图片可能就放置在 domain.com 网站的页面上 SetEnvIfNoCase Referer "^/" local_ref # 直接通过地址访问 SetEnvIf Referer "^$" local_ref 然后再规定被标记了的访问才被允许

<FilesMatch ".(gif|jpg)"> Order Allow,Deny Allow from env=local_ref </FilesMatch> 或者 <Directory /web/images> Order Deny,Allow Deny from all Allow from env=local_ref </Directory> 这方面的文章网上很多,参考: ? ? ? Apache 下防止盗链的解决办法 Apache 的环境变量设置 配置 Apache 实现禁止图片盗链 不要使用 Rerferer 的地方 不要把 Rerferer 用在身份验证或者其他非常重要的检查上,因为 Rerferer 非常容易在客户 端被改变,不管是通过上面介绍的 Firefox 扩展,或者是 Privoxy,甚至是 libcurl 的调用, 所以 Rerferer 数据非常之不可信。

如果你想限制用户必须从某个入口页面访问的话,与其使用 Referer,不如使用 session, 在入口页面写入 session,然后在其他页面检查,如果用户没有访问过入口页面,那么对应 的 session 就不存在,参见这里的讨论 。不过和上面说的一样,也不要过于相信这种方式 的“验证”结果。

除了用在防盗链,其他用途最多的就是访问统计,比如统计用户都 个人感觉现在 Rerferer 除了用在防盗链,其他用途最多的就是访问统计 是从哪里的链接访问过来的等等。

第一篇:referer

Request.Referer 的乱码终极解决方法+获得用户是用什么关键 字通过搜索引擎进来的 分类

ASP.NET2009-12-10 18:08 255 人阅读 评论(0) 收藏 举报 当你想获取 Url 字符串的时候,最好不要直接调用 Request.UrlReferrer.ToString()方法,因 为这样有可能返回的是一堆乱码。

产生的原因是, 用户在来你网站之前的那个网站的编码方 式(Encoding)也许和你的网站不一样,导致 Url Decode 的时候出现了乱码。这里建议使用 Request.UrlReferrer.OriginalString,这个属性返回的就是当时构造 Uri 对象的原始 Url。

以下为获得用户是用什么关键字通过搜索引擎进来的方法 view plaincopy to clipboardprint? 1. string Regx = ""; 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. } if (RefUrl.Contains("sogou.com")) { RefUrl = HttpUtility.UrlDecode(RefUrl, System.Text.Encoding. GetEncoding("gb2312")); } if (RefUrl.Contains("soso.com")) { RefUrl = HttpUtility.UrlDecode(RefUrl, System.Text.Encoding. GetEncoding("gb2312")); Regx = "w=(?<key>[//w*%+]*).*"; } if (RefUrl.Contains("baidu.com")) { RefUrl = HttpUtility.UrlDecode(RefUrl, System.Text.Encoding. GetEncoding("gb2312")); Regx = "wd=(?<key>[//w*%+]*).*"; string RefUrl = Request.UrlReferrer.OriginalString; // Response.Write(HttpUtility.UrlDecode(RefUrl,System.Text.Encodi ng.GetEncoding("gb2312"))); if (RefUrl.ToLower().Contains("google")) { RefUrl = HttpUtility.UrlDecode(RefUrl, System.Text.Encoding. GetEncoding("utf-8")); Regx = "&q=(?<key>[//w*%+]*).*"; 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. [c-sharp] view plaincopy Regx = "query=(?<key>[//w*%+]*).*"; } if (RefUrl.Contains("yahoo.com")) { RefUrl = HttpUtility.UrlDecode(RefUrl, System.Text.Encoding. GetEncoding("utf-8")); Regx = "p=(?<key>[//w*%+]*).*"; } if (RefUrl.Contains("bing.com")) { RefUrl = HttpUtility.UrlDecode(RefUrl, System.Text.Encoding. GetEncoding("utf-8")); Regx = "q=(?<key>[//w*%+]*).*"; } if (Regx == "") { ForSearcherDiv.Visible = false; return; } Regex r = new Regex(Regx); // 定义一个 Regex 对象实例 Match m = r.Match(RefUrl); // 在字符串中匹配 // Response.Write("<br>"+Regx); //Response.Write("<br>" + m.Success.ToString()); if (m.Success) { SearchKey = m.Groups["key"].Value; } 1. string Regx = ""; 2. 3. 4. 5. 6. 7. 8. 9. } if (RefUrl.Contains("baidu.com")) string RefUrl = Request.UrlReferrer.OriginalString; // Response.Write(HttpUtility.UrlDecode(RefUrl,System.Text.Encodi ng.GetEncoding("gb2312"))); if (RefUrl.ToLower().Contains("google")) { RefUrl = HttpUtility.UrlDecode(RefUrl, System.Text.Encoding. GetEncoding("utf-8")); Regx = "&q=(?<key>[//w*%+]*).*"; 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. { RefUrl = HttpUtility.UrlDecode(RefUrl, System.Text.Encoding. GetEncoding("gb2312")); Regx = "wd=(?<key>[//w*%+]*).*"; } if (RefUrl.Contains("soso.com")) { RefUrl = HttpUtility.UrlDecode(RefUrl, System.Text.Encoding. GetEncoding("gb2312")); Regx = "w=(?<key>[//w*%+]*).*"; } if (RefUrl.Contains("sogou.com")) { RefUrl = HttpUtility.UrlDecode(RefUrl, System.Text.Encoding. GetEncoding("gb2312")); Regx = "query=(?<key>[//w*%+]*).*"; } if (RefUrl.Contains("yahoo.com")) { RefUrl = HttpUtility.UrlDecode(RefUrl, System.Text.Encoding. GetEncoding("utf-8")); Regx = "p=(?<key>[//w*%+]*).*"; } if (RefUrl.Contains("bing.com")) { RefUrl = HttpUtility.UrlDecode(RefUrl, System.Text.Encoding. GetEncoding("utf-8")); Regx = "q=(?<key>[//w*%+]*).*"; } if (Regx == "") { ForSearcherDiv.Visible = false; return; } Regex r = new Regex(Regx); // 定义一个 Regex 对象实例 Match m = r.Match(RefUrl); // 在字符串中匹配 // Response.Write("<br>"+Regx); //Response.Write("<br>" + m.Success.ToString()); if (m.Success) { SearchKey = m.Groups["key"].Value; 49. 50. } 什么是 HTTP Referer 简言之, HTTP Referer 是 header 的一部分, 当浏览器向 web 服务器发送请求的时候, 一般会带上 Referer,告诉服务器我是从那个页面链接过来的,服务器籍此可以获得一些信 息用于处理。可以用于统计访问本网站的用户来源,也可以用来防止盗链接(注意:用这种 方法来防止盗链接有很大的局限性,因为 Header 中的信息很容易伪造)。在.NET 中取得 该字段非常简单,你只需要做如下调用即可:Request.UrlReferrer,该值返回的是一个 Uri 对象。值得注意的是,当你想获取 Url 字符串的时候,最好不要直接调用 Request.UrlReferrer.ToString()方法,因为这样有可能返回的是一堆乱码。产生的原因是, 用户在来你网站之前的那个网站的编码方式(Encoding)也许和你的网站不一样,导致 Url Decode 的时候出现了乱码。这里建议使用 Request.UrlReferrer.OriginalString,这个属性 返回的就是当时构造 Uri 对象的原始 Url,即没有经过 Decode 操作。当然,如果你只是想 获取 Url 字符串的话,还可以这样调用:Request.Headers["Referer"]。但你得先判断一下 浏览器是否发送了该值,如果没有发送该值,则返回 null。(小提示:细心的人可能看出来 了,在 HTTP Header 中 Referer 的不是英文单词 Referrer。Referer 其实应该是英文单词 Referrer,不过拼错的人太多了,所以编写标准的人也就将错就错了。但在.NET 中修改了 这个错误,所以是 Request.UrlReferrer,而不是 Request.UrlReferer,使用的时候小心一 点就是了) Referer 不能正确获取 Firefox 中关于 Referer 的设置有两个键值:network.http.sendRefererHeader (default=2) 设置 Referer 的发送方式,0 为完全不发送;1 为部分发送;2 为始终发送。我检查了我的 Firefox 设置,明明设置的是 2 啊,也就是说都要发送这个字段的,但我调试的时候发现 Firefox 确实没有发送这个字段,Request.UrlReferrer 始终为 null。于是上网去找找有没有 解决的办法,发现有很多人和我遇到了相同的问题,但都没有说明原因,也没有找到合适的 解决方案。在微软的官方网站,好像有人提交了这个 Bug,请参考 http://connect.microsoft.com/VisualStudio/feedback /ViewFeedback.aspx?FeedbackID=103334。搞了半天,微软回复说没法重现这个 Bug。

FT。。。除了 Firefox 外,其他几个浏览器 IE,Safari,好像都有这个问题。

查找解决办法 在网上找了一阵,还是无果而终。于是我自己观察了网站的访问日志,发现并不是所有 的 Firefox 的访问记录 Url Refferrer 都是空的,有的确是正确的发送了信息的。我开始还怀 疑是 FF 的版本问题,于是我去下载了 FF 的最新版本 3.0.8,装上之后结果依然。看来不是 版本的问题。我仔细想了一下,出现这样的情况无非有两个原因:第一,FF 没有正确发送 Refferrer 到服务器;第二,FF 正确发送了 Refferrer,服务器的.NET 程序没能正确截取该 值。为了查看 FF 是否正确发送了 Refferre,我用了一个网络抓包工具,把 FF 发送的数据 抓回来分析了一番,惊奇的发现在 FF 发送的 Header 正确的发送了 Refferrer。如下所示: Accept-Charset

gb2312,utf-8;q=0.7,*;q=0.7 Keep-Alive

300 Connection

keep-alive Referer

/s?wd=%C3%C0%C3%FB%CC%DA Cookie

.... 这样一来,就彻底排除了 FF 没有正确发送的问题。难道是 Server 没能正确识别 FF 发 送的 Refferrer?我开始还是有点怀疑的, 可是仔细一想, 除了 Refferrer 没能正确处理以外, 其他的 Header 都是正确的啊,.NET 不会傻到这种程度的,所以我觉得还是客服端在发送 数据的时候出了问题。这时候,我突然想到很多防火墙软件会扫描网络数据包。会不会是防 火墙截断了 FF 发送的 Refferrer 呢?我机器上是 OEM 的诺顿防火墙,由于一直用诺顿,我 对他还是有些好感的。为了验证我的想法,我暂时关闭了诺顿的 Internet 监控功能。重新试 了一遍之前的访问操作, 惊奇的发现这次我的访问记录里面正确提取了 Refferrer。

到这里, 我大概就明白了,肯定是诺顿自动去掉了 Header 中的 Refferrer 信息!!这个时候,我重 新测试了 IE,Safari 等浏览器,都能正确获取 Refferrer 值了。到此为止,这个问题算是找 到答案了,诺顿去掉了我的浏览器发送的 Header 中的 Refferer 信息!!我的问题是解决 了, 不知道网上其他那些遇到同样问题的朋友是否也是防火墙的原因。

希望我的经历对此有 些帮助。

referer》出自:金链花美文网
链接地址:http://www.nongyeqq.com/content/8OZrHdMHgWttqaVZ.html

网站地图 | 关于我们 | 联系我们 | 广告服务 | 免责声明 | 在线留言 | 友情链接 | RSS 订阅 | 热门搜索
版权所有 金链花美文网 www.nongyeqq.com

referer