淘宝如何跨域获取Cookie分析最近在发现使用Taobao的时候的一个小细节，于是便萌发起了写这篇文章。当我们在
淘宝如何跨域获取Cookie分析
最近在发现使用Taobao的时候的一个小细节，于是便萌发起了写这篇文章。
当我们在 www.taobao.com 中进行登录之后，然后直接切换到 www.tmall.com 域名下，发现www.tmall.com首页的最顶部马上显示成了”您好, andyfaces“，于是便对此处的实现机制进行分析。
首先，用户名应该是存储在cookie中的，于是在taobao.com的域名中用 firefox看到用户名确实是存储在 cookie, 而tmall.com中没有存储该cookie:
可以确定的是对于cookie来说肯定是不允许垮域访问的。无论是通过JS还是Server端程序来说都是如此，那么tmall.com是如何访问到taobao.com下的cookie的呢?
于是打开 tmall.com，然后使用firebug来进行调试，发现了一条这样的请求语句，
其页面的JS代码为：
<script> KISSY.getScript("http://www.taobao.com/go/app/tmall/login-api.php?"+Math.random()) </script> 看到这里之后于是也大概知道他如何处理了的，为了确认一下，于是搜索一下 KISSY.getScript 函数代码，确实采用了JS跨域的 JSONP 解决方案：
getScript: function(url, success, charset) { var isCSS = RE_CSS.test(url), node = doc.createElement(isCSS ? 'link' : 'script'), config = success, error, timeout, timer; node.src = url; node.async = true; scriptOnload(node, function() { if (timer) { timer.cancel(); timer = undef; } S.isFunction(success) && success.call(node); // remove script if (head && node.parentNode) { head.removeChild(node); } }); head.insertBefore(node, head.firstChild); } 其原理是通过动态create js include 动态加载js，然后为该script节点bind onload事件或判断onreadystatechange，其具体细节可以参考以上 scriptOnload 的函数的处理。 当js加载完成之后 采用回调方式来执行 success 函数。
为了进一步确实，于是使用 Jquery的 $.getScript 来测试一把，首先在 taobao.com下进行登录成功，然后随便在本地写了一个测试页，通过以下语句:
$.getScript('http://www.taobao.com/go/app/tmall/login-api.php?0.6783450077710154', function(){ console.log("the taobao.com cookie object:" + userCookie + " username:" + userCookie._nk_);}); Firbug结果：
其实大致原理如此，通过在www.taobao.com 的server端提供一个获取当前域下所有cookie的 php的请求地址，然后该php获取到cookie之后将期并成 js 代码，也就是以上第二个截图所看到的。然后再在 tmall 采用 jsonp 的方式跨域加载该 js 代码，从而实现 cookie 的跨域访问。
啊哦,不好意思,该接口不对外部人员开放!啊哦,不好意思,该接口不对外部人员开放!
我用httpclient模拟了一下,现在应该是加上Referer检查了.
如果不加Rederer,就会返回"啊哦,不好意思,该接口不对外部人员开放!";
如果加上"get.addHeader("Referer", "http://www.tmall.com");" (经测试http://www.alimama.com也行)还是可以正确返回的登录信息的.
测试方法是先使用firebug 在浏览器里面把"http://www.taobao.com/go/app/tmall/login-api.php?xxx"这个请求的的内容抓取,然后在代码里在提交get前在head里加上抓取来的Cookie即可.
啊哦,不好意思,该接口不对外部人员开放!
我用httpclient模拟了一下,现在应该是加上Referer检查了.
如果不加Rederer,就会返回"啊哦,不好意思,该接口不对外部人员开放!";
如果加上"get.addHeader("Referer", "http://www.tmall.com");" (经测试http://www.alimama.com也行)还是可以正确返回的登录信息的.
测试方法是先使用firebug 在浏览器里面把"http://www.taobao.com/go/app/tmall/login-api.php?xxx"这个请求的的内容抓取,然后在代码里在提交get前在head里加上抓取来的Cookie即可.
从我测试来看,现在是在服务端对Referer进行检查.假如是类似方式的话,我想进一步问一下,如果有淘宝的同学或者其他有经验的哥们帮忙回答一下:
针对这个过滤Referer的需求,该怎么管理?就像我测试的,除了tmall,alimama也是可以的,那么假如明天淘宝又多个业务入口比如abc,而这个abc完全由另外一个部门维护,那么有什么内部机制可以在abc上线前驱动这段"过滤Referer"的代码进行修改?
我想到的方式:
1.这个过滤原本就是公用的模块,不需要各部门额外维护,增加abc后,在公用模块添加一下即可.但是这个需要非常强大和很细节的前期设计能力.
2.内部存在一个部门负责这种总体的协调,但是这就意味了,这个部门给知道很多分项目的实现细节,并且能在新加入abc的时候立刻意识到还有这样一段"过滤Referer""的代码需要修改.
3.abc先开发,测试出问题,找出问题后,通知其他部门修改这段代码. 在这个问题上,这种方式确实可以奏效,因为这是个一测就会出明显问题的情况.但是是否存在那种很不明显隐藏很深的情况?这对测试用例的覆盖就是硬性的要求了.而且,这也意味了无论设计还是架构都出现了无能为力,无法完全覆盖控制风险的情况.啊哦,不好意思,该接口不对外部人员开放!
我用httpclient模拟了一下,现在应该是加上Referer检查了.
如果不加Rederer,就会返回"啊哦,不好意思,该接口不对外部人员开放!";
如果加上"get.addHeader("Referer", "http://www.tmall.com");" (经测试http://www.alimama.com也行)还是可以正确返回的登录信息的.
测试方法是先使用firebug 在浏览器里面把"http://www.taobao.com/go/app/tmall/login-api.php?xxx"这个请求的的内容抓取,然后在代码里在提交get前在head里加上抓取来的Cookie即可.
从我测试来看,现在是在服务端对Referer进行检查.假如是类似方式的话,我想进一步问一下,如果有淘宝的同学或者其他有经验的哥们帮忙回答一下:
针对这个过滤Referer的需求,该怎么管理?就像我测试的,除了tmall,alimama也是可以的,那么假如明天淘宝又多个业务入口比如abc,而这个abc完全由另外一个部门维护,那么有什么内部机制可以在abc上线前驱动这段"过滤Referer"的代码进行修改?
我想到的方式:
1.这个过滤原本就是公用的模块,不需要各部门额外维护,增加abc后,在公用模块添加一下即可.但是这个需要非常强大和很细节的前期设计能力.
2.内部存在一个部门负责这种总体的协调,但是这就意味了,这个部门给知道很多分项目的实现细节,并且能在新加入abc的时候立刻意识到还有这样一段"过滤Referer""的代码需要修改.
3.abc先开发,测试出问题,找出问题后,通知其他部门修改这段代码. 在这个问题上,这种方式确实可以奏效,因为这是个一测就会出明显问题的情况.但是是否存在那种很不明显隐藏很深的情况?这对测试用例的覆盖就是硬性的要求了.而且,这也意味了无论设计还是架构都出现了无能为力,无法完全覆盖控制风险的情况.
测试方法是先使用firebug 在浏览器里面把"http://www.taobao.com/go/app/tmall/login-api.php?xxx"这个请求的的内容抓取,然后在代码里在提交get前在head里加上抓取来的Cookie即可. 啊哦,不好意思,该接口不对外部人员开放!
我用httpclient模拟了一下,现在应该是加上Referer检查了.
如果不加Rederer,就会返回"啊哦,不好意思,该接口不对外部人员开放!";
如果加上"get.addHeader("Referer", "http://www.tmall.com");" (经测试http://www.alimama.com也行)还是可以正确返回的登录信息的.
测试方法是先使用firebug 在浏览器里面把"http://www.taobao.com/go/app/tmall/login-api.php?xxx"这个请求的的内容抓取,然后在代码里在提交get前在head里加上抓取来的Cookie即可.
从我测试来看,现在是在服务端对Referer进行检查.假如是类似方式的话,我想进一步问一下,如果有淘宝的同学或者其他有经验的哥们帮忙回答一下:
针对这个过滤Referer的需求,该怎么管理?就像我测试的,除了tmall,alimama也是可以的,那么假如明天淘宝又多个业务入口比如abc,而这个abc完全由另外一个部门维护,那么有什么内部机制可以在abc上线前驱动这段"过滤Referer"的代码进行修改?
我想到的方式:
1.这个过滤原本就是公用的模块,不需要各部门额外维护,增加abc后,在公用模块添加一下即可.但是这个需要非常强大和很细节的前期设计能力.
2.内部存在一个部门负责这种总体的协调,但是这就意味了,这个部门给知道很多分项目的实现细节,并且能在新加入abc的时候立刻意识到还有这样一段"过滤Referer""的代码需要修改.
3.abc先开发,测试出问题,找出问题后,通知其他部门修改这段代码. 在这个问题上,这种方式确实可以奏效,因为这是个一测就会出明显问题的情况.但是是否存在那种很不明显隐藏很深的情况?这对测试用例的覆盖就是硬性的要求了.而且,这也意味了无论设计还是架构都出现了无能为力,无法完全覆盖控制风险的情况.
关于“我用httpclient模拟了一下”，这位大侠，我也想做测试。没成功。
能不能发你的代码 给我。qeekey@126.com
54 楼 wwkevin811 2012-03-14 看完后，有两个问题：
1 淘宝这种方式获取回来COOKIE后，在交由服务器端校验，是不是有延时的问题。就是“页面已经展示出来了后”，然后服务器端菜判断用户在线， 再由页面显示出来“这样的问题？
2 如果通过在tmall.com挂一个隐藏的taobao.com, iframe是否可以达到类似的效果呢？
