菜鸟-手把手教你把Acegi应用到实际项目中(5)
??? 在实际企业应用中，用户密码一般都会进行加密处理，这样才能使企业应用更加安全。既然密码的加密如此之重要，那么Acegi(Spring Security)作为成熟的安全框架，当然也我们提供了相应的处理方式。
?
??? 针对用户密码的加密工作，DaoAuthenticationProvider同时暴露了passwordEncoder和saltSource属性。PasswordEncoder和SaltSource是可选的属性，PasswordEncoder负责对认证库中的密码进行加解密。而SaltSource则是在产生密码时给它加点“盐”，以增强密码在认证库中的安全性。Acegi安全系统提供的PasswordEncoder实现中包括MD5、SHA和明文编码。
Acegi提供了三种加密器：
??PlaintextPasswordEncoder---默认，不加密，返回明文.
??ShaPasswordEncoder---哈希算法(SHA)加密
??Md5PasswordEncoder---消息摘要(MD5)加密
Acegi安全系统提供了两个SaltSource的实现：
??SystemWideSaltSource，它用同样的"盐"对系统中所有的密码进行编码
??ReflectionSaltSource只对从UserDetails对象返回的获得这种"盐"的指定属性进行检查。请参考JavaDoc以获取对这些可选特性的更详细信息。
????? 图1为Acegi内置的PasswordEncoder继承链。默认时，DaoAuthenticationProvider会实例化PlaintextPasswordEncoder对象，即应对用户密码未进行加密处理的情况。
?
????? 图2为Acegi内置的SaltSource继承链。默认时，SaltSource的取值为null，即未启用密码私钥。
?
?
1、?PlaintextPasswordEncoder明文密码
????? 在使用明文密码期间，如果系统允许登录用户不区分密码大小写，则应设置ignorePasswordCase属性值为true。
?在Acegi安全配置文件中添加：
?
2、?ShaPasswordEncoder哈希算法（SHA）加密
????? 在Acegi安全配置文件中添加：?
3、?Md5PasswordEncoder消息摘要（MD5）加密
????? 在Acegi安全配置文件中添加：?
4、?SystemWideSaltSource
????? SystemWideSaltSource会采用一个静态字符串表示密码私钥(salt)，所有用户的密码处理都会采用这一私钥。同未启用密码私钥相比，SystemWideSaltSource更为安全，因为它使得密码的破解变得更困难。默认时，它会采用“密码{密码私钥}”形式加密密码。
????? 配置如下：?
5、?ReflectionSaltSource
????? 尽管采用SystemWideSaltSource能够加强密码的保护，但由于SystemWideSaltSource采用了全局性质的密码私钥，因此仍存在一定的缺陷。
????? 而ReflectionSaltSource采用了个案性质的密码私钥，即其密码加密所采用的私钥是动态变化的，因此它更为安全。ReflectionSaltSource仍采用“密码{密码私钥}”的形式加密密码。
????? 配置如下：?
????? 此时，ReflectionSaltSource将调用UserDetails对象的getUsername()方法获得各用户的密码私钥。比如：javaee(用户名)/password(密码) 用户的密码将被以“password{javaee}”的形式进行加密处理。
?????? 通过指定userPropertyToUse属性的值，开发者能够控制密码私钥的来源。比如上述的getUsername的含义就是动态调用相应的getUsername()方法，并将返回结果直接作为密码的私钥。在实际企业应用中，Acegi应用开发者可能会提供自身的UserDetails实现类，这时userPropertyToUse属性的取值范围更加广泛。?
?6、?在web.xml中，我提供了三种方式方便大家调试
?
<property name="userDetailsService" ref="userDetailsService" />
这里的inMemDaoImpl， userDetailsService实现有没有什么要求？ 是否必须是spring 的 DaoSupport 的实现？ 自己的dao规范可否？ <property name="userDetailsService" ref="userDetailsService" />
这里的inMemDaoImpl， userDetailsService实现有没有什么要求？ 是否必须是spring 的 DaoSupport 的实现？ 自己的dao规范可否？
可以自己提供，也有一定的规范，请参考:
菜鸟-手把手教你把Acegi应用到实际项目中(8)-扩展UserDetailsService接口
http://zhanjia.iteye.com/blog/259441 3 楼 windywindy 2009-07-28 使用MessageDigestPasswordEncoder，Md5PasswordEncoder，这些函数加密的，就没有解密的函数吗？我找了一下没找着，麻烦LZ告知！ 4 楼 adamzzww 2009-07-29 用户密码一般都会进行加密处理，这样才能使企业应用更加安全。windywindy 写道使用MessageDigestPasswordEncoder，Md5PasswordEncoder，这些函数加密的，就没有解密的函数吗？我找了一下没找着，麻烦LZ告知！
数据验证，同样加密验证好啦，不用解密吧.. 5 楼 daquan198163 2009-07-29 这标题起的：菜鸟，过来，我手把手教你配Acegi 6 楼 liuchaoyong 2009-07-30 这标题起的：菜鸟，过来，我手把手教你配Acegi ，比较牛 7 楼 zhanjia 2009-08-03 daquan198163 写道这标题起的：菜鸟，过来，我手把手教你配Acegi
理解有误啊，是因为我觉得自己还是菜鸟。
意思是说：我是 菜鸟，我手把手教你...
请原谅啊，不要误导了人家，罪过... 8 楼 zhanjia 2009-08-03 windywindy 写道使用MessageDigestPasswordEncoder，Md5PasswordEncoder，这些函数加密的，就没有解密的函数吗？我找了一下没找着，麻烦LZ告知！
有些加密算法是可逆的，有些是不可逆的。
不可逆加密算法的特征是加密过程中不需要使用密钥，输入明文后由系统直接经过加密算法处理成密文，这种加密后的数据是无法被解密的，只有重新输入明文，并再次经过同样不可逆的加密算法处理，得到相同的加密密文并被系统重新识别后，才能真正解密。所以比较安全
