Super Group

社会裁决那边也要加上。

感觉麻烦的不单是登录,还有两边都要注册.还是把用户名和密码都同步了的好,只需要一处注册和登录就行了,我那边以后肯定也要这样搞.

看好好学习你是怎么考虑的，我觉得以后正式开发的时候肯定要设计统一的授权机制的，还要考虑和真实身份结合起来，不可能依托论坛的用户表，用户的数据应该是以小超人为核心。
现在只是一个实验性质的临时解决方案，没必要作的很完美。

我说的是临时方案,以后的话我们可能都要自己搞一套交流系统替代论坛,这个以后(可能要一年后再说),在论坛存在的这段时间,最好实现同步.如果我来做,我会先研究清楚phpwind是怎么注册和授权的,然后在用户注册phpwind的时候让phpwind发用户的用户名和密码给我们的系统,就实现了注册的同步,然后授权的话,当用户登录了phpwind的时候,可以插入一个iframe来登录我们的系统,cookie插入浏览器就可以了(其中ie的iframe cookie有个p3p问题要弄一下)

回复@好好学习，使用帝国万能会员接口，可以将自己的新系统与phpwind的会员系统进行接洽，帝国万能会员接口相当于一个中间件。

经过思考，我认为原先在qq群里讨论的做法不是很恰当。先把该做法概述如下：
1。应用系统(可能多个)和单点登陆服务器(惟一一个) 约定一个密钥k。
2。应用系统把用户登录请求转到单点登陆服务器，并附带一个随机生成的hash(用k加密)。
3。单点登陆服务器认证用户以后，跳回应用系统，带上userId和解密后的hash。
4。应用系统比对hash，认可userId。
以上做法我认为有以下缺点：
1。需要在所有系统(包括应用系统和单点登陆服务器)存储密钥k。
2。需要应用系统存储hash，增加了应用程序修改的复杂度。

我建议我们还是使用cas的工作模式，这样对应用系统修改较少(于是增加应用系统容易)，主要的修改在单点登陆服务器(在当前情况下是论坛)。
原理见：http://www.blogjava.net/security/archive/2006/10/02/sso_in_action.html

我简单写了一下伪代码：
1. app
String userId = session.get("userId");
if (userId == null) {
String serviceTicket = request.get("serviceTicket");
if (serviceTicket != null) {
userId = ssoServer.getUserId(serviceTicket); // 只能使用一次，相对短的有效期(比如5分钟)
}
if (userId == null) {
redirect(ssoServer);
return;
}
session.set("userId", userId);
}
accessApp(userId);

2. sso server
String tgc = cookie.get("ticketGrantingCookie"); // 相对长的有效期(比如120分钟)
if (tgc == null || isExpired(tgc)) {
redirect(login);
return;
}
String serviceTicket = newServiceTicket();
save(serviceTicket, userId);
return serviceTicket;

3. sso login
// after login
String tgc = newTicketGrantingCookie();
cookie.set("ticketGrantingCookie", tgc);

String serviceTicket = newServiceTicket();
    save(serviceTicket, userId);
    return serviceTicket;

说明1：通过serviceTicket取userId的方法，个人觉得提供一个url即可，因为serviceTicket只能使用一次。
说明2：ticketGrantingCookie是最需要保护的，尽可能使用ssl。

使用以上方式，应用的修改比较容易。