最近在使用sina微博时，经常性交替使用 weibo.com 和 t.sina.cm.cn进入我的微博。发现当我在 t.sina.com.cn中登录之后，直接切换至weibo.com，这时候在 weibo.com是已经登录的，当我在 weibo.com进行注销之后，再切换至 t.sina.com.cn，这时候在 t.sina.com.cn也已经是注销的状态了。
对于SSO的实现方案及其机制，早已经不是什么新鲜的技术了，从微软为.net提供的passport机制到java中开源的JBoss SSO、Oracle OpenSSO及经典的 Yale CAS等等之类的开源或一些商业SSO中间件都不失为作为单点登录实现的选择。当然一些企业也会选择自己实现一套适合自己轻量级方案，如采用SESSIONID转递或SESSION同步复制之类的。 可以看得出SSO的价值也是具大的，就拿sina来说吧，增加 weibo.com域名之后，对于用户来说来说没有任何影响，即使你在 t.sina.com.cn中进行登录，可以无缝在两域名之间随意切换，对于它推广weibo.com无非是大大的益处。
由于近年来一直在使用 Yale的CAS作为SSO的方案，觉得 SINA的SSO与Yale-CAS有很多异曲同工之妙，于是便对SINA的SSO进行分析，其中的细节处理还是很值的学习的。当然，由于分析看到的SINA SSO处理都只是一些表现或表面上的东西，再加上其大部分关键的sso js都已经被压缩，及SERVER端的实现机制也只是靠自己的经验及结合CAS的的一些原理进行猜测。其实本文应该叫 <CAS SSO与SINA SSO的实现对比分析>更比较贴切。
好吧，进入正题。
首先是进入 t.sina.com.cn，提交用户名及密码进行登录，通过 Firebug可以看到它通过类似Aajx POST到了 http://login.sina.com.cn/sso/login.php?client=ssologin.js(v1.3.12)，如下图所示：
不难看出，其 http://login.sina.com.cn/sso/login.php 就是类似是 CAS 中的 Server，对sina的所有应用系统提供的统一登录入口。上面的参数中有一个service参数，了解 CAS的GG应该知道 cas 在登录的时候除了username 和 password同样也有一个 service 参数，其CAS该参数含义是子应用系统的服务名标识及登录成功之后所跳转的地址。当然，sina这里使用了 "miniblog"作为微博的服务名，估计他在sso-server端对 miniblog 与登录成功之后的地址进行映射，如 miniblog=http://t.sina.com.cn/，这样就避免了CAS-client中转入service= decodeURIComponent('http://t.sina.com.cn')之类的做法了。
这里的登录与CAS做法一致，将登录验证提交至统一的认证中心进行验证处理，从而避免了跨子域和全域的问题。 验证成功之后路转的路径就是service所向的地址，验证失败之后则返回至当前登录页。下面就SSO中的一些登录方面的核心问题做一些分析，看看SINA和CAS分别是如何处理的：
1.如何授权某个子系统允许其在sso-server进行登录验证呢，类似cas-server中的login-ticket;
对于cas来说，在首次进入 /cas/login页时， 会产生一个一次性的login-ticket，也就是说在提交登录验证前必须向服务器请求一个login-ticket，在登录提交时，需要将用户名及密码以及login-ticket进行提交至 cas-server端，cas-server端确定login-ticket有效后才会对用户名及密码进行认证。
看看sina如何处理的吧，继续看firebug:
以上截图是当我首次进行 t.sina.com.cn时，通过 ajax/jsonp的方式发起的一个请求，可以看到返回的callback函数中的 json 串中包含了 nonce:"SXK19N"的属性，参数名的汉译是“一次”或“一次性”的意思，估计这里的 nonce就是login-ticket，为再一次确实，我再试着提交登录看看，看它是否将该参数POST过去：
果然不出所料， nonce:"SXK19N"作为参数提交过去了，证明所猜测的应该是正确的。
2.比如验证码跨域跨服务器导致从session无法获取的问题，我们曾经遇到过;
貌似sina登录没有涉及到验证码之类的东西，当你多次登录失败之后，它采用的是“您的登录过于频繁，请稍后再试吧”，这种方案确实比验证码要好的多，而且还避免了上面的说的问题。
3. 当我登录失败了，/sso/login.php 如何将登录的错误信息返回给 t.sina.com.cn并让它进行显示呢，如果我登录成功了/sso/login.php 通过什么方式通知t.sina.com.cn呢，因为它这里使用的是ajax方式登录？
对于这方面，cas的处理是将错误信息以参数的方式返回给 client-login，如登录失败，重定向地址： http://cas-client.com?errocode=0，如果登录成功，则直接 重定向至 service 中的url，并生成ST给客户端，表示其已经在cas-server登录成功了。
看看sina如何处理的吧，随便输入一个用户名密码，提交登录，继续通过firebug看看它的处理过程:
再看看t.sina.com.cn 中的html内容的变化：
以上图1中发生了两次请求，第一次登录验证是访问 sso认证中心，它所返回response是一个html内容，第二次请求的地址： http://t.sina.com.cn/ajaxlogin.php framelogin=1&callback=parent.sinaSSOController.feedBackUrlCallBack&retcode=4038&reason=%B5%C7%C2）
再结合以上图2信息，看到 html 中发生了变化，创建了一个 id=ssoLoginFrame 的iframe，于是便可以得出，sina 的登录并非原生的ajax方式，而是通过创建iframe来模拟提交不刷新的登录。也就是说，当用户点击登录提交时，这时候它会通过js创建iframe，将登录提效至该iframe中。
既然已经知道它登录是提交到iframe中，而非ajax方式，那么对于以上截图1中两个请求为什么返回的都是HTML内容就很容易解释了。再回到上面的问题，/sso/login是如何通知t.sina.com.cn登录失败了呢? 首先在以上第一个截图中返回的 HTML包含了一段 javascript:
- location.replace("http://t.sina.com.cn/ajaxlogin.php?framelogin=1&callback=parent.sinaSSOController.feedBackUrlCallBack&retcode=4038&reason=%B5%C7%C2%BC%B3%A%BC%B3%A2%CA%D4%B4%CE%CA%FD%B9%FD%D3%DA%C6%B5%B7%B1%A3%AC%C7%EB%C9%D4%BA%F3%D4%D9%B5%C7%C2%BC");
location.replace("http://t.sina.com.cn/ajaxlogin.php?framelogin=1&callback=parent.sinaSSOController.feedBackUrlCallBack&retcode=4038&reason=%B5%C7%C2%BC%B3%A%BC%B3%A2%CA%D4%B4%CE%CA%FD%B9%FD%D3%DA%C6%B5%B7%B1%A3%AC%C7%EB%C9%D4%BA%F3%D4%D9%B5%C7%C2%BC");
location.replace的意思与location.href类似，同样都是改变当前的URL地址,具体区别及做法可以参考这里及这里。需要注意的这里所说的通过location.replace改变当前的URL其它并非改变t.sina.com.cn的地址，而是第二个截图里iframe中src的地址，因为这段HTML是在iframe中输出的。
在 locaiton.replace 的地址中包含了一个 retcode 及 reason参数，估计这就是当前登录的错误信息。在上面第一个截图的第二个请求实际就是在iframe 中进行的 location.replace操作后的跳转地址。关键看它输出的html内容：
- <html><head>
- <script language='javascript'>
- parent.sinaSSOController.feedBackUrlCallBack({"result":false,"errno":"4038","reason":"\u767b\u5f55\u5c1d\u8bd5\u6b21\u6570\u8fc7\u4e8e\u9891\u7e41\uff0c\u8bf7\u7a0d\u540e\u518d\u767b\u5f55"});</script></head><body></body></html>null
<html><head>
<script language='javascript'>
parent.sinaSSOController.feedBackUrlCallBack({"result":false,"errno":"4038","reason":"\u767b\u5f55\u5c1d\u8bd5\u6b21\u6570\u8fc7\u4e8e\u9891\u7e41\uff0c\u8bf7\u7a0d\u540e\u518d\u767b\u5f55"});</script></head><body></body></html>null
这段js是在 iframe中执行的，所以可以通过 parent 进行访问 t.sina.com.cn中的js，可以肯定 parent.sinaSSOController.feedBackUrlCallBack 就是告诉 t.sina.com.cn 当前已经登录失败了，并且将错误信息传至该入该callback了。至此，已经完成了 /sso/login.php 对 t.sina.com.cn的信息传送。 新浪果然是有一手呀，在CAS中AJAX登录一直都是一个问题，而sina它巧妙的通过iframe+callback 进行实现了。
接着，再看看它对于登录成功之后如何通知 t.sina.com.cn的吧，先看看登录成功之后 sina-sso-server 会做什么，看firebug截图：
重点在于 set-Cookie: tgc=TGT-MTc4NTc0NzM0Mw==-1305003116-ja-D51B2EB107B79FC50D8CA424BFE08907; 哈哈，熟悉CAS的应该会很熟悉这个，没想到SINA的TGT与CAS的TGT不但参数命名，居然连生成的规则也一模一样，估计sina肯定是参考了 cas 的实现机制。关于TGT是什么或其作用可以参考：CAS总结之Ticket篇。另外还有一个就是当登录成功之后，sina-sso-server会将用户登陆名等等放在sina.com.cn根域的cookie中。
然后再看看登录成功之后 sina-sso-server所返回的response内容：
以下是从以上摘取JS部分：
- <script>
- try{sinaSSOController.setCrossDomainUrlList({"retcode":0,"arrURL":["http:\/\/weibo.com\/sso\/crosdom?action=login&savestate=1305607916"]});}catch(e){}try{sinaSSOController.crossDomainAction('login',function(){location.replace('http://t.sina.com.cn/ajaxlogin.php?framelogin=1&callback=parent.sinaSSOController.feedBackUrlCallBack&retcode=0');});}catch(e){}
- </script>
<script>
try{sinaSSOController.setCrossDomainUrlList({"retcode":0,"arrURL":["http:\/\/weibo.com\/sso\/crosdom?action=login&savestate=1305607916"]});}catch(e){}try{sinaSSOController.crossDomainAction('login',function(){location.replace('http://t.sina.com.cn/ajaxlogin.php?framelogin=1&callback=parent.sinaSSOController.feedBackUrlCallBack&retcode=0');});}catch(e){}
</script>
首先再次声明，以上firebug截图中的请求处理，并非 AJAX，而是在 t.sina.com.cn中放了一个iframe，输出的 reponse都会至iframe当中.
以上的js主要重点在于:
- location.replace('http://t.sina.com.cn/ajaxlogin.php?framelogin=1&callback=parent.sinaSSOController.feedBackUrlCallBack&retcode=0')
location.replace('http://t.sina.com.cn/ajaxlogin.php?framelogin=1&callback=parent.sinaSSOController.feedBackUrlCallBack&retcode=0')
还是通过设置当前iframe中src地址，再看看跳转至http://t.sina.com.cn/ajaxlogin.php后的response内容吧：
返回用户信息(从cookie中获取的)，并且还是类似上面的做法，通过 parent.sinaSSOController.feedBackUrlCallBack回调t.sina.com.cn中的js，告诉它这个用户已经登录成功了。
于是t.sina.com.cn便进行跳转至 t.sina.com.cn/dengers 中，从而实现登录。
整体的处理流程如下：
4. 当我在t.sina.com.cn中登录后，切换至weibo.com，weibo.com我应该也是已经登录的，如何做到呢？
对于这个问题，CAS中的处理就是，当我进入 weibo.com的时候，马上跳转至 /cas/login，然后在login中判断cookie是否存在TGT，如果存在，并确定其有效性后，则认为你已经登录，并为你生成一个ST，将ST作为ticket参数使其重定向至 weibo.com?ticket=TG-xxxx 并登录。
看看sina怎么处理的吧，首先我直接在t.sina.com.cn登录成功。然后再新建一个选项卡，输入 weibo.com：
可以看得出，当我进入 weibo.com之后，sina并没有直接进入 weibo.com的主页，而是马上重定向至: http://login.sina.com.cn/sso/login.php?url=http%3A%2F%2Fweibo.com%2F&_rand=1305008634.5127&gateway=1&service=miniblog&useticket=1&returntype=META 与cas的做法确实一致。 再看看该 login.php的Response 信息，主要是JS：
- <script type="text/javascript" language="javascript">
- location.replace("http://weibo.com/sso/login.php?url=http%3A%2F%2Fweibo.com%2F&ticket=ST-MTc4NTc0NzM0Mw==-1305008634-ja-694BA43623A3F72999AE7129A0572048&retcode=0");
- </script>
<script type="text/javascript" language="javascript">
location.replace("http://weibo.com/sso/login.php?url=http%3A%2F%2Fweibo.com%2F&ticket=ST-MTc4NTc0NzM0Mw==-1305008634-ja-694BA43623A3F72999AE7129A0572048&retcode=0");
</script>
看到这里之后，不得不怀疑 SINA 的 SSO 是不是用的就是 CAS 啊！！不但连 TGT 参数名一样，连ST规则及参数名也一模一样，其处理机制也十分相似。
到这里之后就与 CAS 的处理一样了，就不详细写了，可以参考 CAS相关文章。
──────────
PS:由于在分析过程中里面的很多SSO关键JS都压缩了，所以难免会存在误差。 不过SINA的SSO很多细节方面确实处理的很好，作为互联网应用的话，如果单纯的只是把 CAS DOWNLOAD 下来，然后直接配配就用的话很多方面的处理还是很不到位的。 有时间我把我们CAS参考 SINA 调整一下。
到这里，不得不说的一个事情就是，之前在分析淘宝cookie如何跨域获取时，大家都说出了一个taobao的jsonp实际存在一定的安全隐患。后面那个淘宝的GG看到之后加入Refer的判断。而现在，在分析的过程中发现新浪也有这样的问题，可以尝试一下，随便在本地建立一个html，引入jquery，然后使用下面的JS，就可以获取到sina中的登录邮箱名等信息，前提是你需要先在sina中登录：
- $.ajax({url: 'http://t.sina.com.cn/ajaxlogin.php?framelogin=0&callback=?&retcode=0', dataType:'jsonp',
- success:function(data){
- alert(data.userinfo.userid);
- }});
$.ajax({url: 'http://t.sina.com.cn/ajaxlogin.php?framelogin=0&callback=?&retcode=0', dataType:'jsonp',
success:function(data){
alert(data.userinfo.userid);
}});
分享到：
相关推荐
所谓SSO认证，通俗的一点讲就是，自己写的app需要使用新浪或腾讯微进行分享、发表微博等操作。如果用户的手机客户端安装了符合SSO认证的新浪、腾讯等微博客户端版本且已登录，则会自动启动新浪、腾讯等微博客户端...
**正文** 微博SDK，全称为Sina Weibo Software Development Kit，是新浪官方为开发者提供的一套集成工具，便于在Android...通过深入理解SDK的各个部分，开发者可以轻松实现微博社交功能，提升应用的用户体验和互动性。
今天我们将聚焦于“新浪微博2模拟登陆”这一主题，学习如何通过编程方式模拟登录并获取AccessToken，以便进行自动化操作或者数据分析。 首先，我们需要了解什么是模拟登陆。模拟登陆是指通过编程代码来模拟用户在...
对于Android开发者来说，集成Facebook、Google服务和新浪微博的SSO授权需要遵循特定的步骤和使用相应的SDK。以下是详细的过程： **1. 新浪微博接入流程：** 首先，你需要从官方GitHub仓库...
这个SDK包含了Android平台上实现微博登录、分享、获取用户信息等核心功能所需的类库和文档，让开发者可以方便地集成到自己的应用中，提升用户体验并扩大应用的社交影响力。 在描述中提到的"新浪微博联合登陆api sdk...
在Java编程环境中，实现微博登录通常需要以下步骤： 1. **导入依赖库**：使用像`HttpURLConnection`或`OkHttp`这样的HTTP客户端库，它们可以帮助我们发送HTTP请求。 2. **构建登录请求**：创建一个POST请求，设置...
这个“新浪微博android sdk”包含了一系列必要的组件、文档和示例代码，使得开发者能够轻松地实现与新浪微博的交互，比如用户登录、分享内容、获取用户信息等功能。以下是这个SDK的一些核心知识点： 1. **API文档**...
总结来说，QQ和新浪微博授权登录提供了安全且便捷的用户认证方式，简化了用户的登录体验，同时也帮助开发者快速实现用户管理功能。在实际开发中，需要注意处理好用户隐私和安全问题，确保授权流程的顺畅，同时遵守两...
3. **错误处理**：在实现微博登录功能时，必须考虑到可能出现的错误情况，如授权失败、令牌过期等，要有相应的错误处理机制。 4. **响应式设计**：为了适应不同设备的用户，登录界面应具有良好的响应式设计，确保在...
在PHP中，使用cURL库可以实现模拟用户登录和执行特定任务，例如在本例中是登录新浪微博并发布微博。cURL库提供了一个功能强大的接口，用于与远程服务器进行交互，包括发送HTTP请求、设置请求头和POST数据等。 首先...
所谓SSO认证，通俗的一点讲就是，自己写的app需要使用新浪或腾讯微进行分享、发表微博等操作。如果用户的手机客户端安装了符合SSO认证的新浪、腾讯等微博客户端版本且已登录，则会自动启动新浪、腾讯等微博客户端...
基于JWT实现SSO单点登录流程图解 基于JWT实现SSO单点登录流程图解是指使用JSON Web Token（JWT）来实现单点登录（SSO）的机制。在这种机制中，用户只需要登录一次，就可以访问多个应用服务器上的资源，而不需要再次...
在本文中，我们将深入探讨如何使用OAuth2协议模拟登录新浪微博，并了解相关技术细节。OAuth2是一种授权框架，允许第三方应用代表用户与服务提供商进行交互，例如发布微博。在这个例子中，我们将使用Java的Apache ...
spring boot整合spring security 实现SSO单点登陆 完整DEMO. 1、配置本地hosts 127.0.0.1 sso-login 127.0.0.1 sso-resource 127.0.0.1 sso-tmall 127.0.0.1 sso-taobao windows系统的路径在C:\WINDOWS\system...
在本文中，我们将深入探讨如何使用SSM（Spring MVC、Spring、MyBatis）框架结合Redis缓存来实现SSO功能。 首先，了解SSO的核心原理是关键。SSO主要依赖于票据（Ticket）的概念，当用户成功登录到一个系统时，服务器...