[Please make sure to select the branch corresponding to the version of Thymeleaf you are using]
Status
This is a thymeleaf extras module, not a part of the Thymeleaf core (and as such following its own versioning schema), but fully supported by the Thymeleaf team.
This repository contains two projects:
- thymeleaf-extras-springsecurity3 for integration with Spring Security 3.x
- thymeleaf-extras-springsecurity4 for integration with Spring Security 4.x
Current versions:
- Version 3.0.2.RELEASE - for Thymeleaf 3.0 (requires Thymeleaf 3.0.3+)
- Version 2.1.3.RELEASE - for Thymeleaf 2.1 (requires Thymeleaf 2.1.2+)
License
This software is licensed under the [Apache License 2.0] (http://www.apache.org/licenses/LICENSE-2.0.html).
Requirements (3.0.x)
- Thymeleaf 3.0.0+
- Spring Framework version 3.0.x to 4.3.x
- Spring Security version 3.0.x to 4.2.x
- Web environment (Spring Security integration cannot work offline)
Maven info
- groupId:
org.thymeleaf.extras
- artifactId:
- Spring Security 3 integration package:
thymeleaf-extras-springsecurity3
- Spring Security 4 integration package:
thymeleaf-extras-springsecurity4
Distribution packages
Distribution packages (binaries + sources + javadoc) can be downloaded from SourceForge.
Features
This module provides a new dialect called org.thymeleaf.extras.springsecurity3.dialect.SpringSecurityDialect
or org.thymeleaf.extras.springsecurity4.dialect.SpringSecurityDialect
(depending on the Spring Security version), with default prefix sec
. It includes:
- New expression utility objects:
-
#authentication
representing the Spring Security authentication object (an object implementing theorg.springframework.security.core.Authentication
interface). -
#authorization
: a expression utility object with methods for checking authorization based on expressions, URLs and Access Control Lists. - New attributes:
-
sec:authentication="prop"
outputs aprop
property of the authentication object, similar to the Spring Security<sec:authentication/>
JSP tag. -
sec:authorize="expr"
orsec:authorize-expr="expr"
renders the element children (tag content) if the authenticated user is authorized to see it according to the specified Spring Security expression. -
sec:authorize-url="url"
renders the element children (tag content) if the authenticated user is authorized to see the specified URL. -
sec:authorize-acl="object :: permissions"
renders the element children (tag content) if the authenticated user has the specified permissions on the specified domain object, according to Spring Source's Access Control List system.
Configuration
In order to use the thymeleaf-extras-springsecurity3 or thymeleaf-extras-springsecurity4 modules in our Spring MVC application, we will first need to configure our application in the usual way for Spring + Thymeleaf applications (TemplateEngine bean, template resolvers, etc.), and add the SpringSecurity dialect to our Template Engine so that we can use the sec:*
attributes and special expression utility objects:
<bean id="templateEngine" class="org.thymeleaf.spring4.SpringTemplateEngine">
...
<property name="additionalDialects">
<set>
<!-- Note the package would change to 'springsecurity3' if you are using that version -->
<bean class="org.thymeleaf.extras.springsecurity4.dialect.SpringSecurityDialect"/>
</set>
</property>
...
</bean>
And that's all!
Using the expression utility objects
The #authentication
object can be easily used, like this:
<div th:text="${#authentication.name}">
The value of the "name" property of the authentication object should appear here.
</div>
The #authorization
object can be used in a similar way, normally in th:if
or th:unless
tags:
<div th:if="${#authorization.expression('hasRole(''ROLE_ADMIN'')')}">
This will only be displayed if authenticated user has role ROLE_ADMIN.
</div>
The #authorization
object is an instance of org.thymeleaf.extras.springsecurity[3|4].auth.Authorization
, see this class and its documentation to understand all the methods offered.
Using the attributes
Using the sec:authentication
attribute is equivalent to using the #authentication
object, but using its own attribute:
<div sec:authentication="name">
The value of the "name" property of the authentication object should appear here.
</div>
The sec:authorize
and sec:authorize-expr
attributes are exactly the same. They work equivalently to a th:if
that evaluated an #authorization.expression(...)
expression, by evaluating a Spring Security Expression:
<div sec:authorize="hasRole('ROLE_ADMIN')">
This will only be displayed if authenticated user has role ROLE_ADMIN.
</div>
These Spring Security Expressions in sec:authorize
attributes are in fact Spring EL expressions evaluated on a SpringSecurity-specific root object containing methods such as hasRole(...)
, getPrincipal()
, etc.
As with normal Spring EL expressions, Thymeleaf allows you to access a series of objects from them including the context variables map (the #vars
object). In fact, you are allowed to surround your access expression with ${...}
if it makes you feel more comfortable:
<div sec:authorize="${hasRole(#vars.expectedRole)}">
This will only be displayed if authenticated user has a role computed by the controller.
</div>
Remember that Spring Security sets a special security-oriented object as expression root, which is why you would not be able to access the expectedRole
variable directly in the above expression.
Another way of checking authorization is sec:authorize-url
, which allows you to check whether a user is authorized to visit a specific URL or not:
<div sec:authorize-url="/admin">
This will only be displayed if authenticated user can call the "/admin" URL.
</div>
For specifying a specific HTTP method, do:
<div sec:authorize-url="POST /admin">
This will only be displayed if authenticated user can call the "/admin" URL
using the POST HTTP method.
</div>
Finally, there is an attribute for checking authorization using Spring Security's Access Control Lists, which needs the specification of a domain object and the permissions defined on it that we are asking for.
<div sec:authorize-acl="${obj} :: '1,3'">
This will only be displayed if authenticated user has permissions "1" and "3"
on domain object referenced by context variable "obj".
</div>
In this attribute, both domain object and permission specifications are considered to be thymeleaf Standard Expressions.
Namespace
The namespace for both Spring 3 and 4 versions of this dialect is http://www.thymeleaf.org/extras/spring-security
.
<html xmlns:sec="http://www.thymeleaf.org/extras/spring-security">
Getting the namespace incorrect won't impact processing of your template. It might however impact your IDE when it comes to things like suggestions/auto-completion in your templates.
https://github.com/thymeleaf/thymeleaf-extras-springsecurity
spring boot以其众多友谊的特性,如零配置、微服务等,吸引了很多的粉丝。而其与Spring Security安全框架的无缝结合,使其具备的安全的特性。在此基础上使用Thymeleaf模板引擎进行渲染,静动态结合,让页面开发更加简单、直观。
通过表单提交登录的用户名和密码是登录接口比较常见的一种设计。在初学的过程中,我也不例外的采用个这种方式。表单设计见下图。
登录成功,完成正常的主页面跳转,这个不存在问题。存在问题的是,登录失败了该咋办呢?我就在考虑,由于thymeleaf的局部刷新操作,登录失败了将登录失败的异常信息显示在登录页面,也就是表单上。于是,我的登录设计又变成了如下图所示的表单。
通过这种方法,当登录表单验证失败时,会该用户显示”用户名或密码错误,请重试”,这当然是比较好的,但是验证失败的情况不仅仅是用户名或密码错误吧,应该还有其它的情形,比较常见的就有,该用户已被锁定,该用户不存在,请先注册等。
那么该如何区分这么情形呢,怎么把登录表单验证失败的比较详细的状况显示给用户呢。经过一段时间的调研,发现Spring boot提供了比较完美的解决方案,而其秘密就在Spring Security的配置中。我项目中的Spring Security配置如下图所示。
而我在阅读Spring Security源码时,当认证失败时,找寻到以下处理的代码
而重点就在saveException函数,而此函数的具体代码如下:
从这段代码中,我们可以清晰的看到,认证失败的异常信息被保存在Session中,如果我们可以读取Session中的信息那么,之前所遇到的问题就迎刃而解了吧。
事实上,事物的发展从来不是一帆风顺的,解决问题也是类似。我了解到Thymeleaf提供了读取缓存Session的方案,就迫不及待的进行尝试,于是乎,我的登录表单又变成了如下模样,红线指出的是Thymleaf缓存的读取方式。
这样就可以显示验证失败的具体信息了吗?经过我的测试,我发现,此信息是未定义。也就是说,模样读取到缓存中的信息。
通过在网上查找资料,我在浩瀚的百度的犄角旮旯里,查找到以下的代码片段。
我如获至宝,仿佛见到了光明。在配置文件配置的时代,可以设置登录失败的跳转页面为”/login.html?error=true”,而我设置的是“/login?error”,那么是否可以设置为类似的true呢?我迫不及待的进行尝试。于是乎,我Spring Security的Java Config又变成了如下的样子。
经过验证,通过这样设置,完美的解决了我遇到的问题,到现在,我仍没有明白设置true的含义,望知道的读者可以告诉小编。
小编来总结哈,在Spring boot +Spring Security + Thymeleaf框架下,通过用户名/密码表单提交,在登录界面获取异常信息的步骤,主要有以下两点:
其一:将登录失败的url设置为”/login?error=true”(即后缀带?error=true),使前端的thymleaf可以读取Session;
其二:Thymeleaf提供的读取缓存中信息的方法${session.SPRING_SECURITY_LAST_EXCEPTION.message},两者缺一不可。
http://blog.csdn.net/sun1021873926/article/details/60332059