Acegi(九) 子类SavedRequestAwareWrapper[Java编程]

上篇中我们对 securityContextHolderAwareRequestFilter的丰富多彩有了个体验, 最后对这个类的名字也做了一个望文生义的注释. 本篇中我们将接着看上篇提到的子类,即SavedRequestAwareWrapper. 这个类在父亲的基业上又有什么新的冲破呢? 这得从它的贤内助说起, 即这个子类的属性savedRequest . 呵呵, 这也恰是组合的好处.

我们看到SavedRequestAwareWrapper类里全部办法的实现都是基于这个贤内助的帮忙. 拿我们熟习的getCookies办法来说, 在履行这个办法时, 先要看贤内助的表情: 假如 savedRequest没什么话说,才能履行父亲所传授的,即父类的办法 super.getCookies();

方才看天下足球的"猖獗的足球", 而上面的内容也仅是我的想像,但愿它较为贴切.

下面,我们看这个贤内助是怎么回事? Ta是何许人也呢? 读源码时发现, 这个SavedRequest没什么后台, 没有担当, 只是实现了 Serializable接口. 那有什么用? 单独地看这个类是不行了, 不过发现这么一条语句: SavedRequest saved = (SavedRequest) session.getAttribute(AbstractProcessingFilter.ACEGI_SAVED_REQUEST_KEY); 这里有一个get,那也应当有"人"set过, 莫非说通往发现之路的进口?

经过一段时间的侦查, 终于发现那别有洞天! 在描写这个洞天前, 先看这么一个实际例子.

在CSDN网站里下载东西, 刚开始时我们先找, 找到一个一看评价不错, 那就下载吧, 可点下载按钮时,CSDN网站把我们引到登录页面, 噢, 本来还没登录呢. 很矫捷地填写了登录信息后,点肯定, 这时CSDN直接就把方才要下载的东西拿出来了. 8错! 登录完后, 没必要再重新找那个链接了. 可这是"8错"是怎么实现的呢?

我们用Acegi里的SavedRequest来描写下这个功效的实现, 当然CSDN不一定是用Acegi来实现的, 这里只是借用下那个情形. 在点"下载"按钮前, CSDN是答应我们浏览的, 也就是我们有匿名浏览的权限, 可当下载时, CSDN发现这个人没有下载的权限, 得让Ta登录. 于是, CSDN里的安全机制让页面跳转到登录界面, 同时,为了用户的利用便利, 把用户方才想下载的那个链接也记了下来, 放到了Session中, 而我们说的 SavedRequest恰是干这个用的. 用户登录后, CSDN的安全机制再从Session中取出方才那个想下载的链接, 于是下载顺利举行了.

下面结合前面介绍的Acegi概念,把这个历程再描写一遍. 方才开始用户找东西时用浏览的权限, 当Ta想下载时, Acegi的 FilterSecurityInterceptor在履行 beforeInvocation办法时发现当前用户没有呼应的权限, 于是 FilterSecurityInterceptor抛出一个 accessDeniedException非常, 这个非常在 ExceptionTranslationFilter里给catch住了, 随后的 handleException时, 由 sendStartAuthentication办法负责 new了一个SavedRequest 对象, 这个对象里恰是装了方才那个链接,随后把这个 SavedRequest对象放进了Session . 于是用户登录, 登录妥当后, AbstractProcessingFilter里的 successfulAuthentication办法出头通过 determineTargetUrl办法从session中取出前面放到session中的 SavedRequest对象, 最后再交由 sendRedirect办法, 把用户想要的东东显目前了眼前.

说了半天了, SavedRequest抢去了大大都的风头, 不过也好, 把这个 SavedRequest研究透了后, SavedRequestAwareWrapper的功效就不攻自破了. 也就是说从历史地角度看清了SavedRequest对象的来龙去脉, SavedRequestAwareWrapper对象的目前问题也就应刃而解了.