接上篇
在对安全有很高限制的地方,我们应该提供视图 供用户操作,不提供基础数据库表。<o:p></o:p>
在我们的技术服务平台上,我们应该考虑使用这种方式,<o:p></o:p>
<o:p> </o:p>
<o:p> </o:p>
1、 注册用户和非注册用户所能访问的资源存放在不同的文件夹中-------------------页面原型人员和开发人员尤其注意<o:p></o:p>
2、 限制用户存放在服务器上的文件数量、大小、格式<o:p></o:p>
比如:在文件上传的时候,要限制用户上传的文件的格式,大小等等,在后台做校验<o:p></o:p>
<o:p> </o:p>
3、 检验I/O的数据<o:p></o:p>
前台使用JS 验证并不能得到让人满意的效果,在服务器端有必要进行再次检验<o:p></o:p>
<o:p> </o:p>
4、 暴力破解<o:p></o:p>
一般都是选用验证码,但是一定要是有背景的验证码<o:p></o:p>
5、 隐私的保护<o:p></o:p>
6、 Web service的安全问题<o:p></o:p>
对此,目前我们要考虑的是AJAX的安全问题。<o:p></o:p>
对AJAX的安全方面目前大家都还在沉迷于它的客户感受,没考虑安全方面问题。<o:p></o:p>
我们在这里能做的就是:<o:p></o:p>
1) 少暴露不必要的业务方法----DWR框架<o:p></o:p>
2) ……… -------dojo框架<o:p></o:p>
3) 不建议使用原始的javaScript + XML来处理AJAX<o:p></o:p>
Web service的问题中还有 XPATH、 XML 、XHTML、WDSL、SOAP等存在着一定的漏洞。<o:p></o:p>
这些在以后做技术服务平台的时候,再去考虑。<o:p></o:p>
7、 每一步动作,均写到日志表<o:p></o:p>
<o:p> </o:p>
为以后出现安全漏洞查找<o:p></o:p>
18、URL重写<o:p></o:p>
<o:p> </o:p>
<o:p> </o:p>
<o:p> </o:p>
<o:p></o:p>
1. 方案选择:<o:p></o:p>
业界对JAVA EE的解决方案是这样的:<o:p></o:p>
1) CA<o:p></o:p>
2) SSL<o:p></o:p>
3) JAAS<o:p></o:p>
4) ACEGI<o:p></o:p>
1.1. CA<o:p></o:p>
对我们来说, 不是多重要,CA需要认证机构发证书
1.2. SSL<o:p></o:p>
在ACEGI中去做
<o:p> </o:p>
1.3. JAAS<o:p></o:p>
编程式的------------------不采用,在此不做介绍,有感兴趣的,找我提供一些资料
<o:p> </o:p>
1.4. ACEGI-----SSO<o:p></o:p>
由于我们要写2套姐妹系统----电子商务网和技术服务平台<o:p></o:p>
就存在着两套用户注册与登陆,这样用户在使用起来比较麻烦,让人反感。<o:p></o:p>
这样就存在一个需求:就是将2套乃至今后更多套的用户的登陆和授权统一起来,集中在一套页面去维护多套系统。<o:p></o:p>
为此,我们就需要单点登陆来处理。<o:p></o:p>
这样就直接使用acegi和cas来进行开发,方便以后系统的扩展和维护。<o:p></o:p>
<o:p> </o:p>
<o:p> </o:p>
<o:p> </o:p>
<o:p> </o:p>
附:<o:p></o:p>
Acegi特性说明:<o:p></o:p>
1、 便携性----方便部署
2、 多认证方式 -------ssl form
3、 保护http请求不需要在web.xml文件中配置,直接在<bean></bean>文件中配置即可-------很好(配置即可)
4、 保护服务层的业务方法
这个只有EJB3才能享受的到,acegi也提供了,只要是POJO受管就可(配置即可)
<o:p> </o:p>
5、 灵活的安全传输通道 ---可以在http https之间灵活的切换(配置即可)
6、 安全性上下文的传播-----------目前还不需要
7、 提供标签库操作
8、 提供remember---me认证----cookie---------------用户登陆
9、 提供EhCache集成
10、 提供优异的Captcha集成
11、 支持Spring的事件机制
12、 很好的国际化问题
13、 提供一流的并发会话处理
<o:p> </o:p>
Acegi简单示例一个<o:p></o:p>
见gww的开发源码。
<o:p> </o:p>