fujieid / jap Goto Github PK

SocialStrategy其中两个构造器：

public SocialStrategy(JapUserService japUserService, JapConfig japConfig, JapCache japCache) {
        super(japUserService, japConfig, japCache);
}

public SocialStrategy(JapUserService japUserService, JapConfig japConfig, AuthStateCache authStateCache) {
        this(japUserService, japConfig);
        this.authStateCache = authStateCache;
}

如果调用第一个构造器，可以传入自己的JapCache实现，但此时似乎就只能使用AuthStateCache的默认实现了。同理，调用第二个构造器也是一样。如果我想同时采用JapCache和AuthStateCache的自己的实现，似乎不是那么友好。

能否对此提供支持？或者jap框架这么设计是特意有所考虑，防止出现一些错误。

com.fujieid.jap.core.strategy.AbstractJapStrategy类中的方法checkAuthenticateConfig似乎存在一些逻辑问题。

protected void checkAuthenticateConfig(AuthenticateConfig sourceConfig, Class<?> targetConfigClazz) throws JapException {
        if (ObjectUtil.isNull(sourceConfig)) {
            throw new JapException(JapErrorCode.MISS_AUTHENTICATE_CONFIG);
        }
        if (!ClassUtil.isAssignable(sourceConfig.getClass(), targetConfigClazz)) {
            throw new JapException("Unsupported parameter type, please use " + ClassUtil.getClassName(targetConfigClazz, true) + ", a subclass of AuthenticateConfig");
        }
    }

我认为这里的逻辑应该是检查sourceConfig所属的类应该是targetConfigClazz本身或是子类。在我的代码中sourceConfig实参为SimpleProperties，它是SimpleConfig的子类。所以这里调用ClassUtil.isAssignable(...)似乎两个参数的位置写反了，因为我描述的这个情况正好满足ClassUtil.isAssignable(...)方法说明上的第二点：2、目标类型是原类型的父类。

同时我也进行了测试：

当源和目标交换一下位置后才是正确的：

SessionJapUserStore的save()方法我认为似乎有一些问题。方法体中的这行代码：

JapTokenHelper.saveUserToken(japUser.getUserId(), token);

需要japUser实例的Id作为参数，但有时japUser并没有设置Id属性，比如实现japuserservice接口中模拟的数据就没有模拟其中的Id属性。
没有设置Id更多是开发者的疏忽，但是目前的报错似乎不是很友好。

Why did you add this feature?

CAS是Central Authentication Service的缩写，**认证服务，一种独立开放指令协议。

1、开源的企业级单点登录解决方案。
2、CAS Server 为需要独立部署的 Web 应用。
3、CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等语言编写的各种web应用。
4、CAS属于Apache 2.0许可证，允许代码修改，再发布（作为开源或商业软件）。

或者纯 token 模式，这样就可以用于任何客户端了。