浏览器三种刷新方式的缓存机制-----单点登录SSO的实现原理---PHP版单点登陆实现方案

一浏览器三种刷新方式所采取的缓存机制

    众所周知浏览器是通过Last-Modified和Expires来处理缓存的，具体机制就不做解释，而在具体调试中发现并不按我们想象的方式进行，其原因很有可能是由于你的不同刷新方式导致。

对于大多数浏览器而言，有三种刷新方式：

• F5
• Ctrl+F5
• “转至”或地址栏里回车

而这三种刷新方式会导致浏览器采取不同的缓存机制：

• F5：不允许浏览器直接使用本地缓存，因此Last-Modified能起作用，但Expires无效
• Ctrl+F5：是强制刷新，因此缓存机制失效
• “转至”或地址栏里回车：正常的访问，Last-Modified和Expires都有效

知道有这么一回事后就不会在调试中感到疑惑了。

 二 利用response设置HTTP头 ----网页缓存的设置 

HTTP头一般用来设置网页的基本属性。可以通过response的setHeader()方法来进行设置。如下代码：

 
 
 

  
<%  
  
        response.setHeader("Pragma","No-cache");  
  


  
        response.setHeader("Cache-Control","no-cache");  
  


  
        response.setDateHeader("Expires",0);    //0表示立即过期
  
%> 
 

都是表示在客户端缓存中不保存页面的拷贝。另外，如：

 
 
 

  
response.setHeader("Refresh","5"); 
 

表示客户端浏览器每隔5秒钟定期刷新一次。

Response.Expires

一般情况下，当用户请求WEB服务器时，服务器把请求回复给客户端。在客户端，浏览器把缓存作为一种加快速度的策略，就是当请求时先检查缓存的情况，如果有就直接调缓存了，而不请求服务器了。 在WEB程序设计中，有时为了防止重复的提交或者严格的次序等，必须让用户的数据立即在使用后就过期，当用户后退时就显示过期而不能继续使用。也算是为安全考虑的吧。 一般，response.expires写在页面的最上端，后面跟的是一个时间，就是过期的时间，0表示立即过期。 -1也是一样的道理，即是-9999也是一样的。

如：登陆验证码，使用Response.Expires = -1可以在登陆失败时点后退按钮后让验证码换一个，而不是原先的那一个。

Response.CacheControl = "no-cache"

设置不缓存在临时文件中，本句是指，上网时看到的图片通常在internet的临时文件都能够找到对应的文件，如果加上这一句就找不到了。

EXP：如果登录页面后，进入后台。从后台再通过 后退 按钮 实现 前台页面判断 是否登录 读取登录信息。刷新此页面 的意思 就是不读缓

二使用缓存技术优化网站访问

  　HTTP Caching 用好了，可以极大的减小服务器负载和减少网络带宽。十分有必要深入了解下 http 的 caching 协议。　先来看下请求/响应过程：

http 请求/响应

　　1、用 Last-Modified 头

　　在第一次请求的响应头返回 Last-Modified 内容，时间格式如：Wed, 22 Jul 2009 07:08:07 GMT。是零时区的 GMT 时间，servlet 中可以用 response.addDateHeader ("Last-Modified"， date.getTime ()); 加入响应头。如图：

last-modified 和 If-Modified-Since

　　Last-Modified 与 If-Modified-Since 对应的，前者是响应头，后者是请求头。服务器要处理 If-Modified-Since 请求头与 Last-Modified 对比看是否有更新，如果没有更新就返回 304 响应，否则按正常请求处理。如果要在动态内容中使用它们，那就要程序来处理了。

　　ps：servlet 取 If-Modified-Since 可以用 long last = requst.getDateHeader ("If-Modified-Since");

　　2、用 Etag 头

　　很多时间可能不能用时间来确定内容是否有更新。那可以用 Etag 头，etag 是以内容计算一个标识。计算的方式可以自己决定，比如可以用 crc32、md5等。

Etag 和 If-None-Match

　　Etag 与 If-None-Match 是对应的，前者是响应头，后者是请求头。服务器要判断请求内容计算得到的 etag 是否与请求头 If-None-Match 是否一致，如果一致就表示没有更新，返回 304 就可，否则按正常请求处理。可以参考：用 HttpServletResponseWrapper 实现 Etag 过滤器

　　3、用 Expires 头，过期时间

　　当请求的内容有 Expires 头的时候，浏览器会在这个时间内不去下载这个请求的内容（这个行为对 F5 或 Ctrl+F2 无效，用 IE7，Firefox 3.5 试了，有效的比如：在地址输入后回车）。

expires 过期时间

　　在 servlet 中可以用 response.addDateHeader ("Expires"， date.getTime ()); 添加过期内容。

　　ps：在 httpwatch 中可以看到 Result 为 (Cached) 状态的。

　　4、用 max-age 的 Cache-Control 头

　    　max-age 的值表示，多少秒后失效，在失效之前，浏览器不会去下载请求的内容（当然，这个行为对 F5 或 Ctrl+F2 无效）。比如：服务器写 max-age 响应：response.addHeader ("Cache-Control"， "max-age=10");

　　 ps：如果你还要加一些 Cache-Control 的内容，比如：private，最好不要写两个 addHeader，而是一个 response.addHeader ("Cache-Control"， "private, max-age=10"); 否则 ie 可能对 max-age 无效，原因它只读第一个 Cache-Control 头。

　　小结：

　　Last-Modified 与 Etag 头（即是方式 1 和2）还是要请求服务器的，只是仅返回 304  头，不返回内容。所以浏览怎么 F5 ，304 都是有效的。但用 Ctrl+F5 是全新请求的（这是浏览器行为，不发送缓存相关的头）。

　　Expires 头与 max-age 缓存是不需要请求服务器的，直接从本地缓存中取。但 F5 会忽视缓存（所以使用 httpwatch 之类的 http 协议监察工具时，不要 F5 误认为 Expires 和 max-age 是无效的）。

　　http 协议监察工具：

　　Firebox：httpfox、live http header

　　IE：httpwatch、iehttpheader

三 单点登录SSO的实现原理

      单点登录SSO（Single Sign On）说得简单点就是在一个多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，也就是用户的一次登录能得到其他所有系统的信任。单点登录在大型网站里使用得非常频繁，例如像阿里巴巴这样的网站，在网站的背后是成百上千的子系统，用户一次操作或交易可能涉及到几十个子系统的协作，如果每个子系统都需要用户认证，不仅用户会疯掉，各子系统也会为这种重复认证授权的逻辑搞疯掉。实现单点登录说到底就是要解决如何产生和存储那个信任，再就是其他系统如何验证这个信任的有效性，因此要点也就以下几个：

• 存储信任
• 验证信任

只要解决了以上的问题，达到了开头讲得效果就可以说是SSO。最简单实现SSO的方法就是用Cookie，实现流程如下所示：

不然发现以上的方案是把信任存储在客户端的Cookie里，这种方法虽然实现方便但立马会让人质疑两个问题：

• Cookie不安全
• 不能跨域免登

对于第一个问题一般都是通过加密Cookie来处理，第二个问题是硬伤，其实这种方案的思路的就是要把这个信任关系存储在客户端，要实现这个也不一定只能用Cookie，用flash也能解决，flash的Shared Object API就提供了存储能力。

一般说来，大型系统会采取在服务端存储信任关系的做法，实现流程如下所示：

以上方案就是要把信任关系存储在单独的SSO系统（暂且这么称呼它）里，说起来只是简单地从客户端移到了服务端，但其中几个问题需要重点解决：

• 如何高效存储大量临时性的信任数据
• 如何防止信息传递过程被篡改
• 如何让SSO系统信任登录系统和免登系统

对于第一个问题，一般可以采用类似与memcached的分布式缓存的方案，既能提供可扩展数据量的机制，也能提供高效访问。对于第二个问题，一般采取数字签名的方法，要么通过数字证书签名，要么通过像md5的方式，这就需要SSO系统返回免登URL的时候对需验证的参数进行md5加密，并带上token一起返回，最后需免登的系统进行验证信任关系的时候，需把这个token传给SSO系统，SSO系统通过对token的验证就可以辨别信息是否被改过。对于最后一个问题，可以通过白名单来处理，说简单点只有在白名单上的系统才能请求生产信任关系，同理只有在白名单上的系统才能被免登录。

以上只是提供了些简单的实现技术，但需要强调的是这只是技术实现而已，仅仅是为了解决上面谈到的一些问题，SSO本身来说并不是什么高科技，有了这个认识比较有利于我们深入探索SSO

四 PHP版单点登陆实现方案

摘要：

本文主要介绍了利用webservice,session,cookie技术，来进行通用的单点登录系统的分析与设计。具体实现语言为PHP。单点 登录，英文名为Single Sign On，简称为 SSO，是目前企业，网络业务的用户综合处理的重要组成部分。而SSO的定义，是在多个应用系统中，用户只需要登陆一次就可以访问所有相互信任的应用系 统。

动机：

用过ucenter的全站登录方式的朋友，应该都知道这是典型的观察者模式的解决方案。用户中心作为subject, 其所属observer的注册和删除统一在ucenter的后台进行。而各个子应用站点都对应一个observer。每次用户中心的登录动作，都会触发 js脚本回调w3c标准的子站登录接口(api/uc.php)。

这种方式的缺点，本人认为主要是两点：1. 子站点过多时，回调接口相应增多，这个在分布子站的量的限制上，如何控制来使登录效率不会太低，不好把握; 2. 当某个子站回调接口出现问题时，默认的登录过程会卡住(可以限制登录程序的执行时间，但相应出现问题子站后面的子站的回调接口就调不到了。

基于以上问题，在实际开发过程中，本人设计了另一套单点登录系统。

一. 登陆原理说明