Spring Security自定义权限控制实践

发表于 | 分类于 | |

本文主要介绍Spring Security进行自定义权限控制的一次实践。使用的是Spring Security 4.X版本，基于XML配置和自定义Spring Security组件类实现。这次实践比较特殊的地方是需要集成公司内部的单点登录系统，也就是登录验证由该系统完成，而不是Spring Security完成，权限控制才由Spring Security完成。另一个特殊的地方是权限控制粒度需要到表级别，也就是不同人对不同表有多种不同操作权限，而对不同表的操作是由同一个方法抽象完成的，页面按钮显示也是跟不同表关联的，所以也需要一些自定义配置，具体实现见正文。

原理

简单介绍下Spring Security的原理。

核心组件主要有两个：一个是登录验证拦截器AuthenticationProcessingFilter，另一个是权限验证拦截器AbstractSecurityInterceptor。两大核心组件又各自包含一些小组件来完成功能。

现在先大概过一遍整个流程，用户登陆，会被AuthenticationProcessingFilter拦截，调用AuthenticationManager的实现，而且AuthenticationManager会调用AuthenticationProvider的authenticate(Authentication authentication)方法来验证用户登录信息，其中Authentication包含了前段页面输入的账号和密码。（不同的Provider调用的服务不同，因为这些信息可以是在数据库上，可以是在LDAP服务器上，可以是xml配置文件上等）。具体地，authenticate(Authentication authentication)会根据authentication.getName()获取用户名，并调用UserDetailsService的loadUserByUsername(String username)方法，从服务器获取该用户的UserDetails，其中返回的UserDetails包含了服务器已经保存好的用户名、密码和对应的权限。将用户输入的用户名和密码(包含在authentication里)和服务器已经保存好的UserDetails进行对比，如果验证通过后会将用户及其权限信息封装到Authentication对象放到spring的全局缓存SecurityContextHolder中，以备后面访问资源时使用。

访问资源（即授权管理），访问url时，会通过AbstractSecurityInterceptor拦截器拦截，其中会调用FilterInvocationSecurityMetadataSource的方法来获取被拦截url所需的全部权限，在调用授权管理器AccessDecisionManager，这个授权管理器会通过spring的全局缓存SecurityContextHolder获取用户的权限信息，还会获取被拦截的url和被拦截url所需的全部权限，然后根据所配的策略（有：一票决定，一票否定，少数服从多数等），如果权限足够，则返回，权限不够则报错并调用权限不足页面。

设计与实现

下面围绕着Spring Security的两大核心组件以及摘要中的需求来讲如何设计和实现自定义权限控制。

这里先给出XML完整配置，方便后续讲解定位到每项配置的含义。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:security="http://www.springframework.org/schema/security"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans.xsd
       http://www.springframework.org/schema/security
       http://www.springframework.org/schema/security/spring-security.xsd">

    <!--  Spring-Security 的配置 -->
    <security:http pattern="/resources/**" security="none"/>
    <security:http pattern="/" security="none"/>
    <security:http pattern="/loginView" security="none"/>
    <security:http pattern="/deniedView" security="none"/>
    <security:http auto-config="false" entry-point-ref="authenticationEntryPoint">

        <!--  Spring-Security 4.X 版本默认开启csrf，这里禁用 -->
        <security:csrf disabled="true"/>

        <security:access-denied-handler ref="customAuthenticationFailureHandler"/>

        <security:custom-filter ref="loginAuthenticationFilter" position="FORM_LOGIN_FILTER"/>
        <security:custom-filter ref="filterSecurityInterceptor" before="FILTER_SECURITY_INTERCEPTOR"/>

    </security:http>

    <!--  自定义登录入口 -->
    <bean id="authenticationEntryPoint"
          class="org.springframework.security.web.authentication.LoginUrlAuthenticationEntryPoint">
        <constructor-arg value="/loginView"/>
    </bean>

    <!--  自定义登录验证filter，不要再用form-login标签，否则可能有冲突 -->
    <bean id="loginAuthenticationFilter"
          class="org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter">
        <!-- 自定义登录验证url，由于这里用qsso内置验证，不要加filterProcessesUrl属性 -->
        <!--<property name="filterProcessesUrl" value="/qlogin"/>-->
        <property name="authenticationManager" ref="authenticationManager"/>
    </bean>

    <!-- 指定一个自定义的authentication-manager :customUserDetailsService -->
    <security:authentication-manager id="authenticationManager">
        <security:authentication-provider user-service-ref="customUserDetailsService">
        </security:authentication-provider>
    </security:authentication-manager>

    <!-- 自定义用户信息获取方式 -->
    <bean id="customUserDetailsService" class="com.qunar.hotconfig.security.CustomUserDetailsService"/>

    <!-- 自定义认证管理,资源,权限  -->
    <bean id="filterSecurityInterceptor"
          class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor">
        <property name="authenticationManager"
                  ref="authenticationManager" />
        <property name="accessDecisionManager"
                  ref="accessDecisionManager" />
        <property name="securityMetadataSource"
                  ref="securityMetadataSource" />
    </bean>

    <!-- 自定义资源权限关系认证 -->
    <bean id="accessDecisionManager"
          class="com.qunar.hotconfig.security.CustomAccessDecisionManager" />

    <!-- 自定义资源权限关系集合 -->
    <bean id="securityMetadataSource"
          class="com.qunar.hotconfig.security.CustomSecurityMetadataSource">
    </bean>

    <!-- 自定义权限验证失败处理 -->
    <bean id="customAuthenticationFailureHandler" class="com.qunar.hotconfig.security.CustomAuthenticationFailureHandler"/>
</beans>

登录验证

XML配置，一般情况下，登录验证使用<form-login>标签（相当于默认的AuthenticationProcessingFilter）就可以完成。

但是这里由于要使用公司内部的单点登录系统，验证是由该系统完成的，所以这里需要自定义配置AuthenticationProcessingFilter，替换（custom-filter标签中position表示替换）默认登录验证实现，不添加filterProcessesUrl属性，同时不要再使用<form-login>标签，否则可能会报冲突。不使用<form-login>标签则登录入口需要使用authenticationEntryPoint指定，配置登录入口的作用是用户没有登录时自动跳转到登录页。

如下几项XML配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<security:http auto-config="false" entry-point-ref="authenticationEntryPoint">
	<security:custom-filter ref="loginAuthenticationFilter" position="FORM_LOGIN_FILTER"/>
</security:http>

<!--  自定义登录入口 -->
<bean id="authenticationEntryPoint"
	class="org.springframework.security.web.authentication.LoginUrlAuthenticationEntryPoint">
	<constructor-arg value="/loginView"/>
</bean>

<!--  自定义登录验证filter，不要再用form-login标签，否则可能有冲突 -->
<bean id="loginAuthenticationFilter"
	class="org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter">
	<!-- 自定义登录验证url，由于这里用qsso内置验证，不要加filterProcessesUrl属性 -->
	<!--<property name="filterProcessesUrl" value="/qlogin"/>-->
	<property name="authenticationManager" ref="authenticationManager"/>
</bean>

<!-- 指定一个自定义的authentication-manager :customUserDetailsService -->
<security:authentication-manager id="authenticationManager">
	<security:authentication-provider user-service-ref="customUserDetailsService">
	</security:authentication-provider>
</security:authentication-manager>

<!-- 自定义用户信息获取方式 -->
<bean id="customUserDetailsService" class="com.qunar.hotconfig.security.CustomUserDetailsService"/>

可以看到上面说的我已经划掉了，因为后来发现其实可以用<form-login>标签，只需要把标签下的login-processing-url设置为一个没有对应controller处理的url即可达到同样的效果。这样上面的xml配置对应的可以简化为下面：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<security:http auto-config="false">
    <security:form-login
        login-page="/login"
        login-processing-url="/slogin"/>
</security:http>

<!-- 指定一个自定义的authentication-manager :customUserDetailsService -->
<security:authentication-manager id="authenticationManager">
    <security:authentication-provider user-service-ref="customUserDetailsService">
    </security:authentication-provider>
</security:authentication-manager>

<!-- 自定义用户信息获取方式 -->
<bean id="customUserDetailsService"                    class="com.qunar.hotconfig.security.CustomUserDetailsService"/>

注意其中的/slogin是没有对应的controller处理的。

虽然登录验证不使用spring security，但验证通过后需要用到用户登录及授权信息，而customUserDetailsService就是用来自定义获取用户授权信息的，要调用该类必须先使用AuthenticationManager的authenticate方法进行验证，而我们已经验证通过了，所以这里构造的用户密码设为空，customUserDetailsService获取的用户密码也为空，这样就能通过authenticate方法并获取用户权限信息并设置到SecurityContextHolder中（当前访问线程的ThreadLocal里）。

后端如下操作，/qlogin是用户登录成功后处理的url：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
@RequestMapping("/qlogin")
   public String login(HttpServletResponse response) {
       String token = request.getParameter("token");
       QUser user = QSSO.getQUser(token);
       UserInfoModel userInfo = userService.getUserInfoByUserId(user.getUserId());
       if (null == userInfo) {
           UserInfoModel newUser = userService.initNewUser(user);
           response.addCookie(userService.saveUserInfo(newUser));
       } else {
           response.addCookie(userService.saveUserInfo(userInfo));
       }

       UsernamePasswordAuthenticationToken autoToken = new UsernamePasswordAuthenticationToken(user.getUserId(), "");
       // 用户名密码认证，会调用loadUserByUsername对比，返回authResult（用户认证信息）
       Authentication authResult = authManager.authenticate(autoToken);
       // 在当前访问线程的ThreadLocal中设置 authResult
       SecurityContextHolder.getContext().setAuthentication(authResult);

       QMonitor.recordOne("Login_Success");
       LOG.info("用户 {} 已登录", user.getUserId());

       return "redirect:/configView";
   }

注意其中的下面几行，其余部分不用关注。

1
2
3
4
5
6
//构造空密码的用户输入信息
UsernamePasswordAuthenticationToken autoToken = new UsernamePasswordAuthenticationToken(user.getUserId(), "");
// 用户名密码认证，会调用loadUserByUsername对比，返回authResult（用户认证信息）
Authentication authResult = authManager.authenticate(autoToken);
// 在当前访问线程的ThreadLocal中设置 authResult
SecurityContextHolder.getContext().setAuthentication(authResult);

然后是customUserDetailsService用来自定义获取用户授权信息，用户的查看、管理员权限 ，以及用户对不同表的权限存在数据库里。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
public class CustomUserDetailsService implements UserDetailsService {

    protected static Logger LOG = LoggerFactory.getLogger(CustomUserDetailsService.class);

    private final UserService userService;
    private final UserPermissionService userPermissionService;

    @Autowired
    public CustomUserDetailsService(UserService userService, UserPermissionService userPermissionService) {
        this.userService = userService;
        this.userPermissionService = userPermissionService;
    }

    @Override
    public UserDetails loadUserByUsername(String username)
            throws UsernameNotFoundException, DataAccessException {

        Set<GrantedAuthority> authoritySet = Sets.newHashSet();

        UserInfoModel userInfo = userService.getUserInfoByUserId(username);

        List<UserPermissionModel> userPermissions = userPermissionService.selectByUserId(username);

        if (userInfo != null){
            authoritySet.add(new SimpleGrantedAuthority("ROLE_READ"));  //有读权限

            if (userInfo.getGroupId().equals("1")){ //有管理员权限
                authoritySet.add(new SimpleGrantedAuthority("ROLE_ADMIN"));
            }

            for (UserPermissionModel userPermission : userPermissions) {
                String fileId = userPermission.getFileId().toUpperCase();
                if (userPermission.getModifyPermission()){ //对表fileId有编辑权限
                    authoritySet.add(new SimpleGrantedAuthority("ROLE_" + fileId + "_MODIFY"));
                }
                if (userPermission.getPublishPermission()){ //对表fileId有发布权限
                    authoritySet.add(new SimpleGrantedAuthority("ROLE_" + fileId + "_PUBLISH"));
                }
            }
        }

        LOG.info("Granted Authorities to {}：", username);
        for (GrantedAuthority grantedAuthority : authoritySet) {
            LOG.info("{}", grantedAuthority.getAuthority());
        }

        return new User(username, "", authoritySet);
    }

}

可以看到用户的权限分为系统查看权限、管理员权限以及对各个表的编辑、发布权限，这些信息都是从数据库获得。用户登录认证通过后（authenticate方法通过），会将这些信息放到SecurityContextHolder（访问线程的threadlocal里），以便后面权限认证使用。

权限验证

一般情况下权限验证使用<intercept-url>标签（相当于默认的AbstractSecurityInterceptor）可以配置访问各个url所需要的权限，或者使用注解配置访问某个方法所需要的权限。

但是这里比较特殊的是用户权限粒度到表级别，为了建立资源（url或方法）——权限的对应关系，将表名放到了url中（尝试过表名放到请求参数中，但spring-security的权限验证器无法获得请求参数，估计spring-security不把请求参数当做资源吧）。这样解析url获得表名使用<intercept-url>标签就不方便，需要自定义AbstractSecurityInterceptor和它的一些组件，如下XML配置的filterSecurityInterceptor。

下面几项XML配置 负责权限验证：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<security:http auto-config="false" entry-point-ref="authenticationEntryPoint">
  <security:access-denied-handler ref="customAuthenticationFailureHandler"/>
  <security:custom-filter ref="filterSecurityInterceptor" before="FILTER_SECURITY_INTERCEPTOR"/>
</security:http>

	<!-- 自定义认证管理,资源,权限  -->
    <bean id="filterSecurityInterceptor"
          class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor">
        <property name="authenticationManager"
                  ref="authenticationManager" />
        <property name="accessDecisionManager"
                  ref="accessDecisionManager" />
        <property name="securityMetadataSource"
                  ref="securityMetadataSource" />
    </bean>

    <!-- 自定义权限验证实现 -->
    <bean id="accessDecisionManager"
          class="com.qunar.hotconfig.security.CustomAccessDecisionManager" />

    <!-- 自定义资源权限对应关系 -->
    <bean id="securityMetadataSource"
          class="com.qunar.hotconfig.security.CustomSecurityMetadataSource">
    </bean>

    <!-- 自定义权限验证失败处理 -->
    <bean id="customAuthenticationFailureHandler" class="com.qunar.hotconfig.security.CustomAuthenticationFailureHandler"/>

securityMetadataSource用来自定义访问某资源所需要的权限关系，如下实现（这里实现的是访问某url所需权限集合中只有一个即可）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
public class CustomSecurityMetadataSource implements FilterInvocationSecurityMetadataSource {

    private static final Logger LOG = LoggerFactory.getLogger(CustomSecurityMetadataSource.class);

    private static final String CONFIG_VIEW = "/configView";
    private static final String PERMISSION_VIEW = "/permissionView";
    private static final String PERMISSION_URL = "/manageUserPermission/CurrentUserPermission";
    private static final String CONFIG_URL = "/manageConfFiles/CurrentConfData";

    private static final Splitter SPLITTER = Splitter.on("/").omitEmptyStrings().trimResults();

    /* 通过url地址获取权限信息的方法 */
    @Override
    public Collection<ConfigAttribute> getAttributes(Object object) throws IllegalArgumentException {
        // 获取当前的URL地址
        FilterInvocation filterInvocation = (FilterInvocation) object;
        String url = filterInvocation.getRequestUrl();
        List<String> urls = Lists.newArrayList(SPLITTER.split(url));
        LOG.info("访问的URL：{}", url);

        Set<ConfigAttribute> attributes = Sets.newHashSet();

        if (url.equals(CONFIG_VIEW)){
            attributes.add(new SecurityConfig("ROLE_READ"));
        }else if (url.contains(PERMISSION_URL) || url.equals(PERMISSION_VIEW)){
            attributes.add(new SecurityConfig("ROLE_ADMIN"));
        }else if (url.contains(CONFIG_URL)){
            if (url.contains("add") ||url.contains("delete")||url.contains("update")){
                attributes.add(new SecurityConfig("ROLE_" + urls.get(2).toUpperCase() + "_MODIFY"));
            }else if (url.contains("publish")){
                attributes.add(new SecurityConfig("ROLE_" + urls.get(2).toUpperCase() + "_PUBLISH"));
            }else {
                attributes.add(new SecurityConfig("ROLE_READ"));
            }
        }

        LOG.info("需要的权限：{}", attributes);
        return attributes;
    }

    @Override
    public Collection<ConfigAttribute> getAllConfigAttributes() {
        // TODO Auto-generated method stub
        return null;
    }

    /* 如果为真则说明支持当前格式类型,才会到上面的 getAttributes 方法中 */
    @Override
    public boolean supports(Class<?> clazz) {
        // TODO Auto-generated method stub
        // 需要返回true表示支持
        return true;
    }

}

accessDecisionManager用来做权限认证，即对比securityMetadataSource获得的访问某url所需权限与SecurityContextHolder中存放到的用户权限，如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
public class CustomAccessDecisionManager implements AccessDecisionManager {

    private static final Logger LOG = LoggerFactory.getLogger(CustomAccessDecisionManager.class);

    private final RefreshAuthenticationTools refreshAuthenticationTools;

    @Autowired
    public CustomAccessDecisionManager(RefreshAuthenticationTools refreshAuthenticationTools) {
        this.refreshAuthenticationTools = refreshAuthenticationTools;
    }

    @Override
    public void decide(Authentication authentication, Object o, Collection<ConfigAttribute> attributes)
            throws AccessDeniedException, InsufficientAuthenticationException {

        //决策之前刷新用户权限信息
        refreshAuthenticationTools.refresh();

        if (null == attributes || attributes.size() == 0) {
            LOG.info("不需要权限认证！");
            return;
        }
        String errMsg = null;
        for (ConfigAttribute attribute : attributes) {
            String needRole = attribute.getAttribute();
            // authority为用户所被赋予的权限, needRole 为访问相应的资源应该具有的权限。
            for (GrantedAuthority grantedAuthority : authentication.getAuthorities()) {
                if (needRole.equals(grantedAuthority.getAuthority())) {
                    LOG.info("{} 权限认证成功！", needRole);
                    return;
                }
            }
            if (needRole.equals("ROLE_READ")){
                errMsg = "没有查看权限！";
            }else if (needRole.equals("ROLE_ADMIN")){
                errMsg = "没有管理员权限！";
            }else if (needRole.contains("MODIFY")){
                errMsg = "没有该配置表的编辑权限！";
            }else if (needRole.contains("PUBLISH")){
                errMsg = "没有该配置表的发布权限！";
            }
        }

        throw new AccessDeniedException(errMsg);
    }

    @Override
    public boolean supports(ConfigAttribute configAttribute) {
        return true;
    }

    @Override
    public boolean supports(Class<?> aClass) {
        return true;
    }
}

以上就是spring security整体实现流程，下面是spring security开发过程中解决的问题.

问题解决

后台修改用户权限后，用户再次发送请求立即刷新权限验证，而不需要重新登录

spring security 默认实现是用户登录后获取权限信息并存起来就不变了，后台修改用户权限后需要用户重新登录才能使用新权限。

思路：实现一个刷新权限的工具类，再每次权限验证时调用该工具类刷新，刷新权限逻辑通过向SecurityContextHolder中存放新权限信息完成，跟/qlogin中那三行代码类似。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class RefreshAuthenticationTools {

    private final AuthenticationManager authManager;

    @Autowired
    public RefreshAuthenticationTools(@Qualifier("authenticationManager") AuthenticationManager authManager) {
        this.authManager = authManager;
    }


    public void refresh(){
        String username = SecurityContextHolder.getContext().getAuthentication().getName();

        UsernamePasswordAuthenticationToken autoToken = new UsernamePasswordAuthenticationToken(username, "");
        // 用户名密码认证，会调用loadUserByUsername对比，返回authResult（用户认证信息）
        Authentication authResult = authManager.authenticate(autoToken);

        // 在当前访问线程的ThreadLocal中设置 authResult
        SecurityContextHolder.getContext().setAuthentication(authResult);
    }
}

然后在AccessDecisionManager类的decide方法执行开始时加入

1
2
3
4
5
6
@Override
public void decide(Authentication authentication, Object o, Collection<ConfigAttribute> attributes)
        throws AccessDeniedException, InsufficientAuthenticationException {

    //决策之前刷新用户权限信息
    refreshAuthenticationTools.refresh();

ajax请求响应页面跳转

有时ajax请求的url会因权限不够而返回请求重定向，但ajax请求类型是xmlhttprequest，不能响应httpservletrequest请求重定向。需要在后端做针对ajax跳转的特殊处理，同时前端js解析后端响应实现跳转，如下

后端的验证失败处理器：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class CustomAuthenticationFailureHandler implements AccessDeniedHandler {

    @Override
    public void handle(HttpServletRequest request, HttpServletResponse response, AccessDeniedException e)
            throws IOException, ServletException {
        String basePath = request.getScheme() + "://" + request.getServerName() + ":" + request.getServerPort()
                + request.getContextPath();
        String errMsg = URLEncoder.encode(e.getMessage(), "utf-8");
        // 如果request.getHeader("X-Requested-With") 返回的是"XMLHttpRequest"说明就是ajax请求，需要特殊处理
        if ("XMLHttpRequest".equals(request.getHeader("X-Requested-With"))) {
            // 告诉ajax是重定向
            response.setHeader("REDIRECT", "REDIRECT");
            // 告诉ajax重定向的路径
            response.setHeader("CONTENTPATH", basePath + "/deniedView?errMsg=" + errMsg);
            response.setStatus(HttpServletResponse.SC_FORBIDDEN);
        } else {
            response.sendRedirect(basePath + "/deniedView?errMsg=" + errMsg);
        }
    }
}

前端加入全局js文件，在ajax结束后解析responseheader：

1
2
3
4
5
6
7
8
9
10
11
12
$.ajaxSetup({
    //设置ajax请求结束后的执行动作
    complete: function (XMLHttpRequest, textStatus) {
        if ("REDIRECT" === XMLHttpRequest.getResponseHeader("REDIRECT")) { //若HEADER中含有REDIRECT说明后端想重定向，
            var win = window;
            while (win !== win.top) {
                win = win.top;
            }
            win.location.href = XMLHttpRequest.getResponseHeader("CONTENTPATH");//将后端重定向的地址取出来,使用win.location.href去实现重定向的要求
        }
    }
});

权限失败页面给出提示缺少何种权限，需要对中文传参编码

后端对要传递的errMsg使用URLEncoder:

1
URLEncoder.encode(e.getMessage(), "utf-8");

前端解析传递来的参数：

1
2
3
4
5
6
7
8
9
<div class="errMsg content-fluid content" style="vertical-align: middle">
    <span id="errMsg"></span>
</div>

<script type="text/javascript">
    window.onload = function () {
        document.getElementById("errMsg").innerText = decodeURI(window.location.search.split("=")[1]);
    }
</script>

其中window.location.search.split("=")[1]是对url参数截取errMsg，这里只考虑了只有这一个参数的情况，所以这句解析比较粗暴。

（ps:更通用的js解析url参数的方法如下）

1
2
3
4
5
6
7
8
9
//获取页面参数
function getQueryString(name) {
    var reg = new RegExp("(^|&)" + name + "=([^&]*)(&|$)");
    var r = window.location.search.substr(1).match(reg);
    if (r !== null) {
        return decodeURI(r[2]);
    }
    return null;
}

上面相应的一行可以替换为document.getElementById("errMsg").innerText = getQueryString(errMsg);

spring-security标签控制页面显示

本来用标签空值按钮是否显示是很方便的，但前提是该按钮是否显示只依赖于用户具有的权限。

而我做的项目应用中按钮是否显示除了依赖用户权限，还依赖于页面元素的值（下拉框），也就是依赖当前用户操作的是哪张表，这需要由页面下拉框获得，这样就稍微麻烦，因为spring-surity标签得到的权限信息是jsp中的变量（服务端传来），而页面元素值是js中的变量（客户端获得），想综合两者就得动点手脚。

方案一：jsp变量中使用js中的值，这需要客户端发送请求获得，然后在spring-surity标签中使用该变量判断权限，但遗憾的是spring-surity标签不支持变量（经过尝试后失败）。

方案二：将jsp中的权限信息带到js中，由js控制按钮显示，可以使用页面隐藏域来将jsp变量传递到js中，传递到js后判断是否由当前表的操作权限，如下：

jsp页面中:

1
2
3
4
5
<%--将权限信息隐藏在页面中，由js获得--%>
<sec:authentication property="principal.authorities" var="authorities"/>
<form style="display: none">
    <input type="hidden" id="authorities" value="${authorities}"/>
</form>

js中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
//选中下拉框并点击查询按钮时，控制页面显示
function showButton() {
    $('#btnDiff').show();
    var authorities = $('#authorities').val().toString();
    var modifyRole = "ROLE_" + selectValue.toUpperCase() + "_MODIFY";
    var publishRole = "ROLE_" + selectValue.toUpperCase() + "_PUBLISH";
    if (authorities.indexOf(modifyRole) !== -1) {
        $('#btnAdd').show();
        $('#btnDelete').show();
        $('#btnEdit').show();
    } else if (authorities.indexOf(publishRole) !== -1) {
        $('#btnRelease').show();
    }
}

session过期跳转到登录页

xml中http标签下添加如下配置：

1
<security:session-management invalid-session-url="/sessionTimeout"/>

其中/sessionTimeout需要对ajax请求做特殊处理，来完成正常跳转，类似上面针对ajax的处理，

在controller中加入如下代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@RequestMapping("/sessionTimeout")
public void handle(HttpServletRequest request, HttpServletResponse response)
    throws IOException, ServletException {
      request.getSession().invalidate();
      String basePath = request.getScheme() + "://" + request.getServerName() + ":" + request.getServerPort() + request.getContextPath();
      // 如果request.getHeader("X-Requested-With") 返回的是"XMLHttpRequest"说明就是ajax请求，需要特殊处理
      if ("XMLHttpRequest".equals(request.getHeader("X-Requested-With"))) {
          // 告诉ajax是重定向
          response.setHeader("REDIRECT", "REDIRECT");
          // 告诉ajax重定向的路径
          response.setHeader("CONTENTPATH", basePath + "/login");
          response.setStatus(HttpServletResponse.SC_FORBIDDEN);
      } else {
          response.sendRedirect(basePath + "/login");
      }
  }

总结

个人体验spring-security有一定的学习成本，笔者从接触到完成也弄了三五天吧。主要它很灵活，如果不是很典型的应用，需要很多自定义。

通过这几天搜索资料发现很多文章都提到了shiro，这是个更简单易用的框架，不过涵盖功能没spring-security全。下面是网上资料对他的一般性介绍：

-Shiro较之SpringSecurity，Shiro在保持强大功能的同时，还在简单性和灵活性方面拥有巨大优势。Shiro是一个强大而灵活的开源安全框架，能够非常清晰的处理认证、授权、管理会话以及密码加密。

-Spring Security除了不能脱离Spring，shiro的功能它都有。而且Spring Security对Oauth、OpenID也有支持,Shiro则需要自己手动实现。

坚持原创技术分享，您的支持将鼓励我继续创作！
分享到：