关于SSO的一些讨论

消息记录（此消息记录为文本格式，不支持重新导入）

================================================================
消息分组:群
================================================================
消息对象:德问——黑客与画家
================================================================

2011/12/14 9:31:37 (411630859)
我现在碰到一个问题，两个方案的徘徊

2011/12/14 9:31:53 (35755359)
恩说说看看呢

2011/12/14 9:32:08 (411630859)
就是手机接入量剧增，单台tomcat受不了

2011/12/14 9:32:33 (411630859)
what can i do?  集群？NIO？

2011/12/14 9:32:42 (35755359)
tomcat负责单一的web服务？

2011/12/14 9:32:51 (411630859)
是的

2011/12/14 9:33:15 ∮泪♂(35755359)
我不知道手机开发里有session这个概念吗？

2011/12/14 9:33:30 大胡子眼镜(411630859)
继续

2011/12/14 9:33:33 大胡子眼镜(411630859)
可以有

2011/12/14 9:34:22 ∮泪♂(35755359)
最简单廉价的方式就是用nginx做代理，后台转到N个tomcat

2011/12/14 9:34:35 大胡子眼镜(411630859)
[表情]

2011/12/14 9:34:42 大胡子眼镜(411630859)
的确是高手

2011/12/14 9:34:49 飞(344607674)
[表情]

2011/12/14 9:35:20 ∮泪♂(35755359)
不用以测试为目的，我们的目的不是为了谁的技术高，是为了大家技术共同提高。

2011/12/14 9:35:36 大胡子眼镜(411630859)
嗯

2011/12/14 9:35:41 飞(344607674)
同意

2011/12/14 9:36:37 色の(449211678)
为什么不搭建 jboss? 他的性能不比猫要好么?

2011/12/14 9:36:55 ∮泪♂(35755359)
jboss要钱吗？

2011/12/14 9:36:54 大胡子眼镜(411630859)
我的确是在问问题啊，那么tomcat和nginx比，为什么nginx适合做代理呢？tomcat的优势又在哪里？

2011/12/14 9:37:09 大胡子眼镜(411630859)
不要钱

2011/12/14 9:37:18 ∮泪♂(35755359)
这2个不是同一个东西，不好比。

2011/12/14 9:37:22 色の(449211678)
我之前需要的 jboss 也不要啊

2011/12/14 9:37:22 大胡子眼镜(411630859)
我们就是搭的jboss

2011/12/14 9:37:30 ^ǒ^波^ǒ^(114602605)
如果有多台linux服务器的话，可以用lvs来做服务器的负载，由硬件服务器去选择访问那台的机子，在每台机子上再做应用服务器的负载

2011/12/14 9:37:44 ∮泪♂(35755359)
恩。都可以的

2011/12/14 9:37:45 色の(449211678)
你们 不会 jboss + 猫吧

2011/12/14 9:38:00 色の(449211678)
这应该是 04/5年的架构方式吧

2011/12/14 9:38:15 大胡子眼镜(411630859)
是的

2011/12/14 9:38:34 色の(449211678)
我那时候刚来北京学习java培训

2011/12/14 9:38:42 色の(449211678)
讲的就是这种架构

2011/12/14 9:38:46 大胡子眼镜(411630859)
现在流行什么架构？

2011/12/14 9:39:18 色の(449211678)
好像 jboss 现在的 servlet容器性能已经很强了啊 不需要猫了吧

2011/12/14 9:39:50 色の(449211678)
从07年之后好长时间没有用过它了 我

2011/12/14 9:40:05 大胡子眼镜(411630859)
那你们常用什么架构呢？

2011/12/14 9:40:13 色の(449211678)
上个月在一朋友公司 看到一个系统 拿 glassfish 搭建的

2011/12/14 9:40:32 ∮泪♂(35755359)
系统咋样

2011/12/14 9:40:35 色の(449211678)
强悍

2011/12/14 9:40:47 大胡子眼镜(411630859)
强在哪里？

2011/12/14 9:40:51 ∮泪♂(35755359)
多大的规模

2011/12/14 9:41:05 色の(449211678)
他们是做 石油的

2011/12/14 9:41:14 色の(449211678)
项目很大

2011/12/14 9:41:20 ∮泪♂(35755359)
噢。

2011/12/14 9:41:20 大胡子眼镜(411630859)
大型系统？

2011/12/14 9:41:22 色の(449211678)
嗯

2011/12/14 9:41:42 ∮泪♂(35755359)
选个适合的，比选一个最大的我觉得好。

2011/12/14 9:41:59 大胡子眼镜(411630859)
glassfish只是web服务吧，业务层用的什么？

2011/12/14 9:42:30 色の(449211678)
不过我不会那个东西 我平常做东西最多用用 resin

2011/12/14 9:43:02 色の(449211678)
glassfish 支持EJB3啊

2011/12/14 9:43:07 大胡子眼镜(411630859)
没猜错的话，也是个j2EE架构

2011/12/14 9:43:45 色の(449211678)
反正这些东西跟我搭不上 与java没什么缘分

2011/12/14 9:44:26 ∮泪♂(35755359)
[表情]

2011/12/14 9:44:27 大胡子眼镜(411630859)
glassfish和jboss这两个，的确适合比较研究下

2011/12/14 9:45:00 色の(449211678)
我之前弄的 单点登录系统 和 第三方接入 都用猫

2011/12/14 9:45:07 色の(449211678)
还可以噻 性能

2011/12/14 9:45:19 色の(449211678)
系统也没有出现问题

2011/12/14 9:45:35 ∮泪♂(35755359)
呵呵。能讲讲你的单点登录是怎么实现的吗？[表情]

2011/12/14 9:46:16 色の(449211678)
我实现的原理 很简单 比如我有 www.t.com 这个域

2011/12/14 9:46:29 ∮泪♂(35755359)
恩。

2011/12/14 9:48:54 ∮泪♂(35755359)
然后呢

2011/12/14 9:48:57 色の(449211678)
在写呢


2011/12/14 9:49:20 ∮泪♂(35755359)
[表情]

2011/12/14 9:53:52 大胡子眼镜(411630859)
？

2011/12/14 9:56:30 飞(344607674)
俺插不上嘴 俺只会PHP 惭愧哦

2011/12/14 9:56:59 色の(449211678)
1. 是否登录校验

www.t.com/user/islogin?jsonp={callback} => [
1. 首先去找 cookie里面是否存在 .t.com 域下的 令牌 tokenket
2. 不存在令牌
3. 展现登录视图
]

www.t.com/user/islogin?jsonp={callback} => [
1. 首先去找 cookie里面是否存在 .t.com 域下的 令牌 tokenket
2. 存在令牌但校验无效
3. 展现登录视图
]

www.t.com/user/islogin?jsonp={callback} => [
1. 首先去找 cookie里面是否存在 .t.com 域下的 令牌 tokenket
2. 存在令牌
3. 令牌有效 -> 通过
]  2. 登录操作

www.t.com/user/logincheck?jsonp={callback} => [
1. 校验帐号信息
2. 正确/错误/异常 []

3. 正确 -> 生成令牌 -> 写入 .t.com 下的tokenket 中
]

2011/12/14 9:57:02 大胡子眼镜(411630859)
色写SSO不会按论文来写了吧[表情]

2011/12/14 9:57:09 色の(449211678)
简单来讲


2011/12/14 9:57:41 色の(449211678)
单点登录 大部分都是这么实现的吧

2011/12/14 9:58:02 色の(449211678)
这几个 场景 应该就是了

2011/12/14 9:58:13 色の(449211678)
里面肯定有些其它的环节

2011/12/14 9:58:47 ∮泪♂(35755359)
恩

2011/12/14 9:58:51 ∮泪♂(35755359)
大概明白了

2011/12/14 9:58:49 大胡子眼镜(411630859)
令牌认证的流程大同小异

2011/12/14 9:58:50 色の(449211678)
比如 生成密钥的算法 个人实现不尽相同 服务器端存储临时令牌的位置

2011/12/14 9:59:09 色の(449211678)
至于第三方接入 在此基础上也能很好扩展

2011/12/14 9:59:16 ∮泪♂(35755359)
所有的页面都需要用这个来进行验证

2011/12/14 9:59:19 色の(449211678)
不一定啊

2011/12/14 10:00:16 大胡子眼镜(411630859)
似乎应该有一个关节，判断用户权限后，分给他几个令牌吧。供不同页面使用？

2011/12/14 10:00:20 色の(449211678)
然后 使用的地方 可以只操作一次 放在一个隐藏的ifr里面 调用 jsonp回调你自己应用的 login操作

2011/12/14 10:00:42 色の(449211678)
sso系统只用来 做用户登录校验

2011/12/14 10:00:57 色の(449211678)
至于用户权限 不同应用自身去实现

2011/12/14 10:01:11 色の(449211678)
sso 模块不管这个

2011/12/14 10:01:22 ∮泪♂(35755359)
隐藏的ifr里面   不同的域 需要跨域 实现吧

2011/12/14 10:01:19 大胡子眼镜(411630859)
callback，这个重要

2011/12/14 10:02:30 大胡子眼镜(411630859)
跨域，怎么搞呢？

2011/12/14 10:03:22 色の(449211678)
不理解你说的跨域的问题

2011/12/14 10:03:48 飞(344607674)
不同域名下，怎么实现

2011/12/14 10:03:54 色の(449211678)
因为此处启用了 jsonp支持

2011/12/14 10:04:08 ∮泪♂(35755359)
实际上我们的系统比较复杂，比如 各自有各自的验证机制，从你的系统获取令牌后，自己给自己写了个验证方式，并且以后都用这个自己的验证方式。一但自己这个验证过期，再从sso去验证登录。    这样就会出现一个问题。 N个系统之间 登录，退出不能同步。

2011/12/14 10:04:06 色の(449211678)
所以 并不会存在什么跨域的问题

2011/12/14 10:04:15 ∮泪♂(35755359)
恩。JSONP 可以。

2011/12/14 10:04:54 色の(449211678)
我现在这边是这么实现的 并不是所有第三方应用都需要 同步退出

2011/12/14 10:05:09 ∮泪♂(35755359)
恩。

2011/12/14 10:05:24 ∮泪♂(35755359)
没有一个完全的办法。

2011/12/14 10:05:36 色の(449211678)
而且 需要同步退出的应用 它们必须单独提出这个申请

2011/12/14 10:05:48 大胡子眼镜(411630859)
jsonp就是靠的js去callback实现跨域的

2011/12/14 10:05:49 色の(449211678)
我上面列出的那个 token

2011/12/14 10:06:15 色の(449211678)
只是 一种 对于需要 同步退出的应用 使用了另外一套 机制

2011/12/14 10:06:59 大胡子眼镜(411630859)
不同入口，同步退出，这个难搞

2011/12/14 10:07:07 色の(449211678)
总的来说 比如就是生成另外一个 tokenkey 对于这样的应用

2011/12/14 10:07:20 ∮泪♂(35755359)
是的。

2011/12/14 10:07:18 色の(449211678)
清楚这个 tokenkey就行

2011/12/14 10:07:43 色の(449211678)
因为每个应用都有对应的 apikey 和 groupkey

2011/12/14 10:08:08 色の(449211678)
对于一组需要同步登录/退出的应用

2011/12/14 10:08:19 色の(449211678)
使用不同的 实现方式

2011/12/14 10:08:33 色の(449211678)
但是 sso的原理 基本就是上述几种情景

2011/12/14 10:08:58 色の(449211678)
这个是我实现时候的理解 你们可以谈谈你们的实现方式

2011/12/14 10:09:52 ∮泪♂(35755359)
没有完美的方案，只有在抛弃某些要求的前提下实现。

2011/12/14 10:10:43 色の(449211678)
本来我一开始也只想到 apikey

2011/12/14 10:11:04 色の(449211678)
后面 竟然有 同一公司的不同应用要接入

2011/12/14 10:11:24 色の(449211678)
但是都想做到 旗下应用退出 其它应用也退出

2011/12/14 10:11:41 色の(449211678)
所以就产生了 groupkey 这么一个东西

2011/12/14 10:12:06 大胡子眼镜(411630859)
java好解决啊，RMI

2011/12/14 10:12:21 色の(449211678)
我总结 sso 尽量越简单,提供的服务越少越好

2011/12/14 10:12:33 色の(449211678)
而且 一定要做好缓存

2011/12/14 10:12:48 色の(449211678)
rmi 性能不高吧

2011/12/14 10:13:02 大胡子眼镜(411630859)
还好吧

2011/12/14 10:13:07 色の(449211678)
PHP的 其实很好实现

2011/12/14 10:13:34 色の(449211678)
我这个实现 也是把以前弄的PHP sso系统 搬过来的

2011/12/14 10:13:53 大胡子眼镜(411630859)
其实我想到了更好的方案

2011/12/14 10:13:55 色の(449211678)
java肯定有更好的模式噻

2011/12/14 10:14:09 色の(449211678)
你给我们分享下你的思路呗

2011/12/14 10:14:52 大胡子眼镜(411630859)
不同入口的同步退出，典型的一对多应用

2011/12/14 10:15:14 ∮泪♂(35755359)
咋同步退出呢

2011/12/14 10:15:30 大胡子眼镜(411630859)
嘿嘿

2011/12/14 10:15:34 大胡子眼镜(411630859)
spread

2011/12/14 10:15:45 大胡子眼镜(411630859)
这个你们玩过吗？

2011/12/14 10:16:05 ∮泪♂(35755359)
没呀

2011/12/14 10:16:06 大胡子眼镜(411630859)
主流门户的核心系统，都用这个

2011/12/14 10:16:37 大胡子眼镜(411630859)
专门处理一对多的同步问题

2011/12/14 10:16:55 ∮泪♂(35755359)
有网址吗?搜索不到

2011/12/14 10:17:19 大胡子眼镜(411630859)
我似乎泄密了

2011/12/14 10:17:43 ∮泪♂(35755359)
不付出哪能得到。

2011/12/14 10:17:40 (10000)
群管理模式已升级，已向用户发送邀请，请等待用户接受。


2011/12/14 10:19:03 老男孩(9399636)
没搞清要解决什么问题

2011/12/14 10:20:01 大胡子眼镜(411630859)
就是一个入口退出，所有应用退出

2011/12/14 10:20:17 ∮泪♂(35755359)
恩。同步退出

2011/12/14 10:20:24 大胡子眼镜(411630859)
比如我退出QQ，那么QQ空间退出

2011/12/14 10:20:41 大胡子眼镜(411630859)
QQ游戏啊，什么的，都自动退出

2011/12/14 10:21:06 色の(449211678)
这个东西咋实现呢

2011/12/14 10:21:24 色の(449211678)
根本就不局限与 浏览器

2011/12/14 10:21:32 老男孩(9399636)
那就要看你session咋实现了

2011/12/14 10:21:45 大胡子眼镜(411630859)
怎么讲

2011/12/14 10:22:04 ∮泪♂(35755359)
不会是用隐藏脚本 调取各个应用的退出接口吧

2011/12/14 10:22:34 色の(449211678)
如果单纯 session的话 会不会每次操作都要去服务器查看是否注销呢?

2011/12/14 10:22:59 ∮泪♂(35755359)
是

2011/12/14 10:22:51 老男孩(9399636)
你只要吧异常机制做好就没问题

2011/12/14 10:23:07 色の(449211678)
继续啊

2011/12/14 10:23:23 大胡子眼镜(411630859)
这个可配置性差，我加了一个入口。是不是又要修改每个key的这个文件

2011/12/14 10:23:27 老男孩(9399636)
你每个服务端的调用都是基于登录用户的

2011/12/14 10:24:08 老男孩(9399636)
如果当前会话的statu没有用户信息了那调用就应该抛异常

2011/12/14 10:24:46 飞(344607674)
正解  所以腾讯的登录很慢

2011/12/14 10:24:45 大胡子眼镜(411630859)
怎么保证当前会话的statu没有用户信息？

2011/12/14 10:25:04 色の(449211678)
难道 服务端的应用 账户系统 不与其它的应用系统分离么?

2011/12/14 10:25:31 色の(449211678)
服务端的应用 难不成 公用 一个 session ?

2011/12/14 10:25:34 老男孩(9399636)
登录就意味着会话保持，如果服务端不保持了，登录就失效，客户端自然回到推出状态

2011/12/14 10:25:46 色の(449211678)
服务端的多个应用 难不成 公用 一个 登录session ?

2011/12/14 10:25:53 大胡子眼镜(411630859)
是啊

2011/12/14 10:25:59 大胡子眼镜(411630859)
色说的对啊

2011/12/14 10:26:14 老男孩(9399636)
那你可以用token传递session呀

2011/12/14 10:26:19 大胡子眼镜(411630859)
客户端不可能用一个session

2011/12/14 10:26:31 大胡子眼镜(411630859)
对啊

2011/12/14 10:26:40 大胡子眼镜(411630859)
还是回到老问题了

2011/12/14 10:26:56 大胡子眼镜(411630859)
token传递，要一个个传，还是广播好？

2011/12/14 10:26:55 老男孩(9399636)
对于不同的域你可以共用session也可以copy session

2011/12/14 10:27:05 色の(449211678)
继续

2011/12/14 10:27:11 飞(344607674)
QQ肯定是有单独登录服务器

2011/12/14 10:27:35 老男孩(9399636)
基于用户行为一个个传了

2011/12/14 10:27:45 老男孩(9399636)
推出基于消息广播

2011/12/14 10:29:56 色の(449211678)
没有理解

2011/12/14 10:30:03 色の(449211678)
能细致点不

2011/12/14 10:30:52 ∮泪♂(35755359)
是不是退出一个应用，然后用消息队列的 广播方式传到各个应用，提醒他该用户退出了。

2011/12/14 10:30:52 老男孩(9399636)
每个服务器基于token传递session，每个服务器都留个退出接口从一个单点调用销毁其他session

2011/12/14 10:31:05 老男孩(9399636)
想想就像路由器一样

2011/12/14 10:32:05 ∮泪♂(35755359)
销毁其他session ？其他sessionid都是一样的吗？

2011/12/14 10:32:02 老男孩(9399636)
如果基于准实时消息提醒那就得有检测机制了

2011/12/14 10:32:44 色の(449211678)
有这方面的文档么

2011/12/14 10:33:02 色の(449211678)
这个 超出了我之前的认知啊

2011/12/14 10:33:14 老男孩(9399636)
可以做个类似路由表的保存当前有哪些登录的session

2011/12/14 10:33:30 ∮泪♂(35755359)
也是一种 实现的方式。

2011/12/14 10:34:20 色の(449211678)
难不成跟 控制帐号登录状态 类似?

2011/12/14 10:34:24 氢离子(245663474)
QQ登陆要session干嘛……

2011/12/14 10:34:50 色の(449211678)
帐号 只允许 单地点登录

2011/12/14 10:35:12 ∮泪♂(35755359)
我觉舍弃现有的session机制。用memcache 来实现，用统一的接口方式实现。这样子销毁其他session还是可以简单些的。

2011/12/14 10:35:28 氢离子(245663474)
用客户端ip限制就可以啦。。。

2011/12/14 10:35:36 氢离子(245663474)
QQ又有客户端的，又不是web的

2011/12/14 10:36:00 色の(449211678)
那如果 我们自己实现这种方案

2011/12/14 10:36:04 色の(449211678)
应该怎么实现呢?

2011/12/14 10:36:02 老男孩(9399636)
session并不特指web容器的session

2011/12/14 10:37:10 氢离子(245663474)
登录时提交了本机IP，并不一定是出口ip，是本机的ip。登陆成功后，服务器记录下来。之后根据设置的心跳记录是否在线。当有新的客户端登录时，就会发现ip变了。。就是新账号登陆啦。。

2011/12/14 10:37:39 ∮泪♂(35755359)
不是这样的。

2011/12/14 10:37:39 氢离子(245663474)
说说

2011/12/14 10:37:51 ∮泪♂(35755359)
先不讨论带客户端的

2011/12/14 10:37:48 氢离子(245663474)
哦。。。这样啊。。

2011/12/14 10:38:03 老男孩(9399636)
你就sso模块统管其他系统的session

2011/12/14 10:38:19 ∮泪♂(35755359)
我觉得难点就是sessionid的无规律性造成的。假如我们自制sessionid

2011/12/14 10:38:31 氢离子(245663474)
sso能控制心跳吗

2011/12/14 10:39:04 ∮泪♂(35755359)
一个用户USER1在一个应用app1上的sessionid即为 user1_app1

2011/12/14 10:38:56 老男孩(9399636)
心跳当然不走sso

2011/12/14 10:39:10 老男孩(9399636)
sso只处理登录和注销

2011/12/14 10:39:32 ∮泪♂(35755359)
用户在这个app1上提交退出申请时

2011/12/14 10:39:50 ∮泪♂(35755359)
在memcache里获取到 user1_app2-n的所有session

2011/12/14 10:39:54 ∮泪♂(35755359)
同时注销。

2011/12/14 10:40:16 ∮泪♂(35755359)
这样就省去了使用路由表记录sessionid了。

2011/12/14 10:40:45 氢离子(245663474)
应该让用户始终定位到同一个mc里，这样省去了去除的问题。

2011/12/14 10:40:58 氢离子(245663474)
通过用户的某个字符串，每次hash都应该到同一个mc比较好

2011/12/14 10:41:14 ∮泪♂(35755359)
mc可以用hash集群，不会有读不到的情况。

2011/12/14 10:41:51 氢离子(245663474)
嗯，确实不会有读不到的问题。只是清理比较麻烦。。你每次定位到同一个mc上。只要修改这个mc的记录就可以实现唯一登陆了

2011/12/14 10:42:05 ∮泪♂(35755359)
session的机制就是在cookie里种下一颗sessionid的种子。

2011/12/14 10:42:10 氢离子(245663474)
so？

2011/12/14 10:42:19 色の(449211678)
我得好好想想 这种思路

2011/12/14 10:42:41 ∮泪♂(35755359)
能解决部分问题。

2011/12/14 10:42:42 氢离子(245663474)
和cookie木有本质的区别，就是在客户端写个东西，不过这个东西是否是由服务器控制而已

2011/12/14 10:43:00 色の(449211678)
确实很有诱惑力啊

2011/12/14 10:43:15 氢离子(245663474)
[表情]你想写个webQQ？

2011/12/14 10:43:24 色の(449211678)
[图片]
z

2011/12/14 10:43:57 色の(449211678)
你们的意思是不是说 有个单独维持 session 的地方

2011/12/14 10:44:14 色の(449211678)
假设就是 session 池 对么?

2011/12/14 10:44:56 氢离子(245663474)
我感觉泪是说把session记录在mc里。。用这个来验证用户唯一性

2011/12/14 10:45:09 飞(344607674)
用memcache存储session 来共享

2011/12/14 10:45:18 ∮泪♂(35755359)
是啊

2011/12/14 10:45:19 色の(449211678)
每次 客户端调用服务器端 数据,服务器端应用 先去这个池里面查询 对应的 session 

2011/12/14 10:45:32 ∮泪♂(35755359)
抛弃现有的session机制

2011/12/14 10:45:52 氢离子(245663474)
色，可查可不查。不查就直接修改让上一个人掉线就行了

2011/12/14 10:46:03 氢离子(245663474)
我感觉应该有个题目。。我们谢谢，还能挣点分

2011/12/14 10:46:19 色の(449211678)
而每个 服务端应用 其实只是起个 session转化池中session的代理的角色

2011/12/14 10:46:57 色の(449211678)
而每个 服务端应用 必须提供一个将自身客户端对应的 session转化池中session的任务

2011/12/14 10:47:31 飞(344607674)
[表情]

2011/12/14 10:48:09 氢离子(245663474)
海飞，又傻笑。。这个功能应该添加到德问上

2011/12/14 10:48:30 飞(344607674)
已经有看

2011/12/14 10:48:33 飞(344607674)
已经有了

2011/12/14 10:48:27 氢离子(245663474)
有啥？聊天功能吗

2011/12/14 10:48:55 飞(344607674)
现在德问的主站和博客站就是通过mc共享session来实现的

2011/12/14 10:49:12 氢离子(245663474)
哦。我说的不是这个。我说的是页面聊天功能。这样就不需要额外的QQ了。也给你的德问增加些流量

2011/12/14 10:49:28 飞(344607674)
聊天你的功能不让加，包括私信的功能也是，防止将来猎头进来骚扰用户

2011/12/14 10:49:34 氢离子(245663474)
[表情]

2011/12/14 10:49:52 飞(344607674)
这是俺个人的 不完全是为了德问 只是一些喜欢技术 喜欢讨论的人分享而已

2011/12/14 10:49:55 色の(449211678)
把这些记录抄到我的博客去 有空好好想想

2011/12/14 10:49:56 氢离子(245663474)
哦。。。

2011/12/14 10:50:18 飞(344607674)
有些问题，大家可以去德问上问，到时候让德问组织活动，邀请你们参加 哈哈

2011/12/14 10:50:14 色の(449211678)
这种方式 得好好消化下

2011/12/14 10:50:28 ∮泪♂(35755359)
你的得问， 哦，不，是你的得问

2011/12/14 10:50:31 氢离子(245663474)
[表情]

2011/12/14 10:50:48 飞(344607674)
[表情]

2011/12/14 10:51:17 氢离子(245663474)
其实老简单了，登陆，记录登陆状态。再登陆，复核登录状态或者把新状态写入，让老状态的下岗