回顾：  前几篇博客中，我们都是在acegi配置文件中配置那些web资源需要保护，这次为了更接近企业开发，我们把web资源角色信息都存放到数据库中。  那既然自己设计表，那么就需要自己重新定义 objectDefinitionSource了，那先看看我们原来acegi的配置：    那默认的调用PathBasedFilterInvocationDefinitionMap类，

前面我们都是使用默认的UserDetailsService，无论是使用InMemoryDaoImpl还是JdbcDaoImpl这种形式。那这篇文章给大家讲解如何自定义userDetailsService，正如咱们前面写过自己的logoutFilter类。  源码讲解  UserDetailsService是个对用户信息操作的接口，其中只有一个方法UserDetails loadUserBy

概括：  前几篇博客中form验证中用户名称、密码都是存在内存中，为了进一步完善，我们把用户基本信息存放到数据库中。  基于内存形式如下： <bean id ="daoAuthenticationProvider" class= "org.acegisecurity.providers.dao.DaoAuthenticationProvid

回顾：    logoutFilter过滤器，我已经带大家了解过了。其中注销是由handler.logout完成的。这就需要在配置文件中配置具体的handler，比如securitycontextlogouthandler，或者tokenbasedremembermeservices,大家可以看到logouthandler具体的实现类如下：     若我程序中就想只用Securit

一个完整的系统应该都要注销功能。先不着急先代码，首先想象一下，注销后，该出现什么页面呢？  注销后，是不是应该回到登陆页面，让用户重新登录，然后再重新判断过滤权限，一切从头开始。  具体开发步骤：  开发环境：  配置文件：    那注销过滤器logoutFilter应用如下：  acegi配置文件中logoutFilter在httpSessionCon

在上一篇博客中《acegi security基于form表单认证-debug调试》中讲述了一个现象，每次重新打开新的浏览器，依然保留着上个页面。针对上个例子来说，要么是当前用户信息、要么是无权限信息。出现这个现象上篇博客我们已经分析过，就是securitycontext中已经存在认证过的权限对象。  那么，我想，重新运行userinfo.jsp页面，重新认证一遍，怎么办啊？唯一的办法，

运行基于form表单的acegitest2demo，你是否发现有什么不妥？  测试不妥处如下：  1.在IE中运行http://localhost:8080/acegitest2/userinfo.jsp  2.肯定会转到login页面，然后登陆进去test/1，进入accessdefined无权限页面。使用lisi/1,进入当前用户信息。  但是：  假如你用test

上篇博客给大家介绍了basic认证，同时也带领大家debug了一下源码，所以流程想必大家都已经了解了，那么现在只剩下各种认证的配置了。  具体步骤如下：  开发环境：  MyEclispe10.7.1+tomcat6.0.37+acegi1.0.5+spring2.0  项目目录如下：  其中readme主要用来记录本次验证目的     配置文件   web

debug调试： 运行：http://localhost:8080/acegitest1/index.jsp 因为web.xml中配置： AcegiFilterChainProxy org.acegisecurity.util.FilterToBeanProxy ta

上篇已经介绍了acegi整体框架，给大家一个感性的认识。那这边博客开始进入代码实践——基于basic认证。  我们已经说到，acegi主要通过过滤连来实现认证和授权操作。  具体步骤如下：  开发环境：MyEclispe10.7.1+tomcat6.0.37+acegi1.0.5+spring2.0  项目目录如下：  其中readme主要用来记录本次验证目的

Acegi Security概念    Acegi Security是基于J2EE的企业软件应用提供全面的安全服务。通俗的说，就是封装的安全框架。提到安全，大家脑子中第一反应肯定是权限控制。的确如此，安全主要的功能就是为了权限控制。   Acegi Security 和Spring Security 是一回事吗?为啥搜索Acegi Security框架，有时会发现一会这样配置，一会那样配置