当前位置： &
新浪微博怎么修改地址
今天格子啦小编为大家带来的是iPhone7越狱后怎么恢复到原厂系统状态教程,本
Hi~ o(*￣▽￣*)ブ~小伙伴们知道新天龙八部手游的十二大门派之一的唐门是怎么样的
今天格子啦小编为大家带来的是怎么把word文字转换成图片教程,在使用word时,我
今天格子啦小编为大家带来的是Win10 Emoji表情怎么使用教程,Win10创意者更新版本
现在使用支付宝的小伙伴已经越来越多了,那么小伙伴们你们知道吗支付宝易积
现在用微信转账的小伙伴已经越来越多了,但是转着转着就有一个问题了,微信转
【亿愿IP免费代理采集验证与应用更换】主要用于(1)采集各种类型的代理IP地址,透明
运行环境:IIS+ASP.NET4.6+SQL2008开发软件:VS2015后台地址:http://t.25175.com:8001/老师或学生根据
【鑫河软件的批量验证邮箱地址工具功能如下】一.本软件可以实现检查以下网络协
ms17010补丁下载地址就在这里,而且是ms17-010补丁win7版,目前该ms17010补丁win7版支持
微软补丁MS17-010下载地址已出,相信不懂得搜索MS17-010的朋友还都在寻找修复“永恒
具备邮件地址分组管理功能的邮件群发器,模拟人工一对一发送,邮件中包含接收
PDF修改器是一款可以对PDF文件进行随意修改的PDF修改软件.其中包括修改PDF文字
PDF编辑软件(PDFEditor)拥有非常高的文件编辑权限.可编辑修改PDF文字、PDF图片、PDF水印
PDFEditor是一款绿色版PDF编辑器.它支持修改编辑PDF文字、插入图片、删除水印、删除页
功能介绍:【亿愿英文文件名批量翻译修改】采用4种翻译引擎,自动识别文件名的语
对于存在安全风险的文件,QQ会自动修改其文件名,即在原有的文件名后增加“.重命
Hi~ o(*￣▽￣*)ブ~小伙伴们大家好!今天小编给大家带来了ocr文字识别软件教程,一起来
【软件介绍】新浪寒刀辅助工具,是由全网最强的页游辅助——新浪页游助手专门针对《寒
新浪永夜大陆辅助工具,是由全网最强的页游辅助——新浪页游助手专门针对《永夜大
小编推荐-新浪微博怎么修改地址新浪微博推“霸王条款”？用户怒了
欢迎投稿，邮箱
还有，我名字念heng，第二声。
关键字: 微博新条款新浪微博用户条款用户条款新浪微博新浪微博用户
【文 观察者网/张珩】大部分商家都有用户条款，其中常常有一句话“最终解释权归本店所有”。实际上，这是一条隐形的“霸王条款”。但是昨天（9月15日）晚上，这种事疑似发生在了一家知名互联网公司身上。
昨晚，所有新浪微博用户突然收到了一条弹窗通知，微博推出了新的用户使用条款，很多人瞬间“怒了”，因为其中的部分内容有“赤裸裸”的“霸王条款”的嫌疑。和当年“3Q大战”类似，用户只能在360或者QQ中选择一个。如今新浪要求，所有人要么把原创的版权交给新浪，要么别用。
新条约洋洋洒洒一长篇，有用户用一句话总结——“我是你爸爸”。
微博究竟说了些什么引发了用户的愤怒呢？争议主要集中在1.3、1.5、8.3和8.4这4款中。具体说了些啥，下面都有说明。
根据微博条款1.3款显示，以后用户在微博平台上发布的一切内容，微博都将享有独家发布平台权益，用户只能在微博上独家展示，未经微博书面允许，用户不得自行授权第三方直接或者间接引用任何内容。
而1.5条款则说，微博用户将无偿授权微博平台法律权力，以任何法律手段追究第三方平台使用在微博上发布的内容等行为，微博将获得所有赔偿款项，同时，用户还承诺配合微博，应微博要求积极提供文件和相关协助。
而在8.3和8.4条款中，微博表示，如果用户违反了有关规定，那么微博有权不通知，立即采取一切手段减轻或者消除用户行为造成的影响，并且由用户承担一切损失和后果。
结果这几项规定一出台，瞬间引发了巨大的争议。重压之下，微博在今天凌晨对1.3和1.5条款进行了修订。
在1.3条款中，微博删除了独家发布平台，用户只能在微博上独家展示等内容，而在1.5条款内，微博删除了用户还承诺配合微博，应微博要求积极提供文件和相关协助的内容。
但是对于8.3和8.4，新浪微博没有进行任何修正。
另外，新浪微博总监王高飞@来去之间对于这个问题也进行了解释。王高飞表示，APP抓了新浪微博的东西直接推送，也没有审核，出了问题就是新浪背锅。
有用户还进行了调侃......
微博上的“大V”们也纷纷质疑新规定。知名博主@马伯庸“马亲王”就质疑了1.3中关于独家版权的争议。对此@来去之间回应说，用户可以自己发给第三方，但是不能授权第三方前来微博抓取，必须通过微博授权。
今天下午新浪微博的官方解释也强调了这一点。
即使如此，马伯庸还是认为在法律上有极大的模糊空间，1.3已经明显超出了限制“第三方抓取”的适用范围，这才是所有人担心的点。
原标题：新浪微博新“霸王条款” 为了限制今日头条？ 请支持独立网站，转发请注明本文链接： 责任编辑:张珩博客分类：
&&&& 最近在使用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的实现对比分析&更比较贴切。
&&
&&& 好吧，进入正题。
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-
&&&&&&& 对于cas来说，在首次进入& /cas/login页时， ，也就是说在提交登录验证前必须向服务器请求一个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的意思与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\u\u4e8e\u\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==--ja-D51B2EB107B79FC50D8CA424BFE08907;& 哈哈，熟悉CAS的应该会很熟悉这个，没想到SINA的TGT与CAS的TGT不但参数命名，居然连生成的规则也一模一样，估计sina肯定是参考了 cas 的实现机制。关于TGT是什么或其作用可以参考：。另外还有一个就是当登录成功之后，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="]});}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')
&&&&& 还是通过设置当前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=.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==--ja-694BA99AE&retcode=0");
&/script&
&&&&& 看到这里之后，不得不怀疑 SINA　的 SSO　是不是用的就是 CAS　啊！！不但连 TGT 参数名一样，连ST规则及参数名也一模一样，其处理机制也十分相似。
&&&&& 到这里之后就与 CAS　的处理一样了，就不详细写了，可以参考 CAS相关文章。
──────────
PS:由于在分析过程中里面的很多SSO关键JS都压缩了，所以难免会存在误差。　不过SINA的SSO很多细节方面确实处理的很好，作为互联网应用的话，如果单纯的只是把 CAS　DOWNLOAD　下来，然后直接配配就用的话很多方面的处理还是很不到位的。　有时间我把我们CAS参考 SINA　调整一下。
到这里，不得不说的一个事情就是，之前在时，大家都说出了一个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);
浏览 20272
论坛回复 /
(22 / 39980)
fangin 写道ln1058 写道我怎么觉得没必要这么麻烦呢。如果是我来做，直接通过cookie来判断用户是否为登录状态，然后在进行相关的URL跳转。这种网站对于用户的安全性都不高，真有必要这么麻烦吗？你不能因为用户禁用cookie就登陆不上去啊你说的没错，不过遗憾的是 sina当你禁用了cookie你确实登录不上去。貌似连iteye也是这样。现在怎样呢？我在firefox中清理并禁用了cookie，微博登陆之后，在sina主页还是看到我已经登陆的信息。
呵呵。新浪动作真快，现在的sso不是你这种模式咯。
是采用P3P协议，t.sina.com.cn登录成功的话，会自动让用户请求一次weibo.com的http://weibo.com/sso/crosdom?action=login&savestate=&callback=sinaSSOController.doCrossDomainCallBack&scriptId=ssoscript0&client=ssologin.js(v1.3.12)&_=5 脚本设置COOKIE
和你说的情况一样，这是一次调用 之后还有一次 是 scriptId=ssoscript1 的，想要用httpclient3 模拟（在Java下）， 关键是后面那个 &_=5实在是不知道怎么获取，前6位事实上是和TGC 中的那个数字前6位一样，但是后面是什么呢？怎么生成的呢，这两次跨域的调用脚本应该是必须模拟的，因为我直接用post后返回的 replace.location 后面的网址是显示cookie:rejected的警告，外加返回responsebody=null 根本什么都没有，有什么方法么？
请楼主再分析一下统一注销是如何实现的吧，我觉得这个比统一登录更难搞哎好的，等放假的时候结合CAS进行分析一下，现在太忙了。
呵呵。新浪动作真快，现在的sso不是你这种模式咯。
是采用P3P协议，t.sina.com.cn登录成功的话，会自动让用户请求一次weibo.com的http://weibo.com/sso/crosdom?action=login&savestate=&callback=sinaSSOController.doCrossDomainCallBack&scriptId=ssoscript0&client=ssologin.js(v1.3.12)&_=5 脚本设置COOKIE
不是新浪改了，而是这一块我没有分析到而已了，sina本身的SSO方式还是没有变的.
首先分析一下为什么在t.sina.com.cn中登录成功之后要在有这段请求吧?
可以肯定的是，这段请求是在 t.sina.com 中的 iframe　中通过&& ajax/jsonp方式发起的，可以看如下图：
估计它是通过在iframe中的这段JS发起的请求：
sinaSSOController.setCrossDomainUrlList({"retcode":0,"arrURL":["http:\/\/weibo.com\/sso\/crosdom?action=login&savestate="]});}
先不管它P3P的目的何在，先看看它这段请求对 weibo.com 域名做了哪些事，下面的截图是当我在 t.sina.com.cn　中登录成功之后，weibo.com中的cookie信息：
绝就绝在这里，它这段cookie是在什么时候加入进去的呢? 可以看出从 t.sina.com.cn中提交用户名到登录成功，整个过程中与weibo.com打过交道的; 只有以上第一个截图中的第二个请求，也就是你所说那个请求，那么就可以肯定的说 weibo.com中的cookie信息是通过在t.sina.com.cn这个域名下的iframe里面采用ajax/jsonp去请求weibo.com去设置的()，，我想你应该猜出为什么 sina.com要使用P3P了。
好吧，再分析它为什么要这么麻烦去设置weibo.com中的cookie吧?
这篇文章中也提到，Sina的SSO判断用户是否已经登录了，是依赖于login.sina.com.cn/sso/login.php中cookie的，类似cas的做法：
denger 写道CAS中的SSO处理就是，当我进入 weibo.com的时候，马上跳转至& /cas/login，然后在login中判断cookie是否存在TGT，如果存在，并确定其有效性后，则认为你已经登录，并为你生成一个ST，将ST作为ticket参数使其重定向至 weibo.com?ticket=TG-xxxx 并登录。如果不存在则重新返回至weibo.com中，需要你进行登录
如果sina是直接采用CAS的做法，每次进入 weibo.com 我都会重定向至& /sso/login.php判断这个用户是否登录过， 那就会造成我本身从来就没有登录过，然后刷新一下或每进入 weibo.com它就会重定向至 /sso/login.php(因为对于weibo.com域来说他不知道你是否已经通过其它域名在/sso/login.php登录成功了)，然后/sso/login.php发现你没有登录过，又给你跳回来weibo.com中让你登录，再次回到weibo.com之后，weibo.com发现你没有登录，又会跳转至/sso/login.php，于是又跳回来...死循环就来了，虽然它可在第一次回到weibo.com的时候加一些标识表示不需要进行再去/sso/login.php了，不过最终这样来回的进行无意义的重定向不太好吧，为什么说无意义呢，因为我本身就从来没有登录过，你为什么还要让我跳转至　/sso/login.php进行自动登录呢？
基于上面的分析，提出的一个问题就是：当我进入weibo.com，我什么时候才需要重定向至 /sso/login.php 进行自动登录呢?&& 于是，基于这个问题，就不难判断出在 t.sina.com.cn中登录成功之后，为什么要去set weibo.com中的cookie了。因为按正常逻辑来说，只有当我已经登录成功过(不管在哪登录成功)，我进入 weibo.com之后你才需要为我重定向至 /sso/login.php去自动登录，而不是进入无意义的重定向。　那么这时候当我在 t.sina.com.cn登录成功，并且在t.sina.com.cn中去设置 weibo.com的cookie，于是我再直接进入 weibo.com，这时候weibo.com首先做的不是直接重定向至 /sso/login.php进行登录，而是判断当前cookie是否存在某个已登的标识，如果存在的话我再重定向至 /sso/login.php进行自动登录，从而避免无意义的重定向。
对于以上的分析，你可以进行测试一下我说的是否符合逻辑：
　　test1: 首先先将你本地的所有sina.com.cn　和 weibo.com中的cookie清空，然后在正常通过　t.sina.com.cn进行登录成功，这时候再新建一个选项卡，直接输入 weibo.com ，你会发现它马上会重定向至 /sso/login.php进行自动登录了。
&&&&& test2: 然后再分别注销，同样再删除sina.com.cn及weibo.com中的cookie，再正常通过 t.sina.com.cn 进行登录成功，这时候打开cookie管理器，将 weibo.com 中的所有cookie再全部删除，然后再新建一个选项卡，直接输入weibo.com，这时候你发现它不会进入重定向至 /sso/login.php了。而此时在weibo.com中是处于非登录状态，而在t.sina.com.cn中是处登录状态。这是因为进入weibo.com它未从cookie找到你已登录的标识，所以它认为你从来没有登录过，于是就不进入 /sso/login.php 进行自动登录了。
&&&&& test3:在sina.com.cn及weibo.com中都处于未登录状态，然后直接进入weibo.com，与test1对比起来，为什么它不会先重定向至 /sso/login.php了呢？在weibo.com中是根据什么来判断是否需要重定向至 /sso/login.php？通过test2的测试我想也不用我说了吧。
　 如果按你说的，那么在test1中t.sina.com.cn中登录成功并且已经设置weibo.com中的cookie，为什么进入weibo.com还要去重定向 /sso/login.php去自动登录呢。
& 上一页 1
浏览: 296803 次
来自: 北京
忘了说我邮箱了
请发一下最github地址给我好吗？不胜感激
求一个github地址.感谢分享
使用您的例子从服务器获取lt返回test-login 页面之后 ...
WANTAWAY314 写道这种方法适合移动端的单点登录不？大 ...
(window.slotbydup=window.slotbydup || []).push({
id: '4773203',
container: s,
size: '200,200',
display: 'inlay-fix'恋爱中最好的状态，就是看谁都可怜恋爱中最好的状态，就是看谁都可怜女人酒馆百家号文丨小北1今天晚上想要给大家分享一篇很虐狗的故事，因为今天也是在微博热搜上看到了这样的主题：恋爱中最好的状态是什么呢？就是看谁都可怜。一听这个题目就是满满的挑衅，那到底怎么样才算是你眼中恋爱中最好的状态是什么呢？我把这个问题发在了微博上，看到很多人留言。有人说，就是“没有你我一个人也能走，但是有你话我能跑起来啊”；也有人说，就是“我这人很笨，但在你的眼中却打了一百分”；还有人说，就是“我做好了和你共度一生的打算，也做好了你随时要走的准备。”而在这么多的回答当中，我们又看到了了一个新的回答那就是：恋爱中最好的状态，就是看谁都可怜。这个意思就是说，当你处在一个很好的恋爱状态的时候，你会不自觉的对别人产生一种同情心，看谁都是可怜的，会为他们不能够体会到自己目前在恋爱中所获得的幸福感，而感到惋惜。我还蛮喜欢这个回答，可能是觉得他说的有几分道理吧。因为当我们都处于一种非常幸福状态的时候，就会被一种甜蜜的感觉包裹到全身，因此你看到谁的时候都觉得不如自己幸福，不得不说，这大概也是幸福的一种很高的境界了吧。2我还记得之前有一位读者给我留言说：还记得我曾经和前任在一起的时候，我经常觉得自己被宠到了天上去，他完全把我这个有一点强势的人，变成了温婉可人的小女孩，连我父母和朋友都觉得那个时候的我可爱多了。虽然现在我们已经分手了，但是我依然觉得，他曾给我的那段感情，让我体会到了最高级的浪漫。你们可以想象吗？就是那时候的我啊，说话总是带着笑意的，连苦难都觉得是包装好的礼物，我跟他在一起的时候会这个时间再也不会难打发了，哪怕只是静静的和他坐在一起，我都觉得这一天是意义非凡的。我想，这应该就是我们恋爱当中最好的状态了吧。会让我们每天都觉得心满意足，平日里滋生出来的幸福感，也是让别人都能体会到的啊。我当时看完这个读者留言的时候，正处于我是失恋的状态，不知道为什么，我觉得她很欠揍，但是呢，又有一种很羡慕的感觉。让我想起我的编辑晓辰刚和他现在老公谈恋爱的时候，那段时间，我就感觉晓辰每天都像泡在蜜罐里的小女孩一样，整天笑个不停。当时我记得，我和她出去跑签售的时候，那一整个晚上我们住在酒店里，她都对着手机屏幕一直傻乐，半夜的时候还在被窝里给对方打电话。连跟我说话的语气从从前的霸道都好像变得温柔于细腻了。我还记得那段时间，我们两个同一部悲剧，她都能够把悲剧看出喜感来，还有她的笑点也是进入了史上的最低值。其实我知道，那是因为她每天都在恋爱的甜蜜感里，所以整个人看上去都好像是被幸福感满满的包围着，连带着在旁边充满负能量的我，也变得甜蜜起来。除此之外，她还经常对我说，你知道吗小北，我现在的每一天都觉得非常的满足，我好像对每一天都充满了希望和期待，而且我完全理解了那些说“我觉得你是世界上最幸福的人”的那种心情。还有一点就是，她还经常觉得我单身很惨，所以总会带我去吃很多好吃的东西，去看很多漂亮的风景，甚至还要为我介绍一个靠谱的男朋友。所以我觉得，她应该看我过成这个样子，产生了同情心吧。其实我很能够理解这种感觉，就是你非常非常喜欢自己现在的生活，所以你就希望你身边的人都和你一样也变得幸福，变得好一点，再好一点。3其实这并不是一种可以拿出来秀的感觉，因为晓辰很少在朋友圈秀恩爱，她也不经常给我讲她和男朋友之间的事，我也很少过问，但是好像我们所有人都能够看到她眼中的幸福。我想这才是恋爱当中最真的一种幸福吧。你从来不必问一个人爱不爱你，因为他的眼睛里他的心里他所做的每一件事情里都写满了答案；你也从来不必问一个人幸不幸福，因为他的样子他的状态他生活的每一个细节里都充满了它。这种最好的状态也从来不是刻意秀出来的，他们已经体会到了恋爱里最真实的甜蜜。他们知道，自己在被人偏爱着，也知道无论有多少人与他为敌，在这个世界上，也总会有这么一个人站在他的背后。这种恋爱状态是让你体会到世界的美好，是让你整个人都充满着正能量，也是让你觉得你会更加希望别人能够和你一样获得幸福。人们总是问谈一场好的恋爱究竟是什么感觉呢？其实我觉得，这个答案就是你遇到这个人之后，每天都想给温暖的日子取一个温暖的名字，总觉得山川河流都繁花似锦，那种由内而外散发出来的喜悦感没有经历过的人是不能够理解的。我希望你能体会到那个人给你的满满爱意，我也希望你在遇见这个人的时候，即使生活贫瘠，也依然觉得生活里每一分每一秒都是值得被你炫耀的。本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。女人酒馆百家号最近更新：简介:女人酒馆分享女人生活故事作者最新文章相关文章