经过前两篇文章的体验，我已经初步接触了Sa-Token的登录、退出、在线状态检测以及前后端分离的实现。这次来体验Sa-Token部分常用配置。

sa-toekn.token-name token名称

首先是前文用到过的token-name，token-name用来指定token的名称，如果不指定，默认的名称是satoken，我们删掉所有配置来测试一下。

这时执行登陆，查看返回内容

可以看到默认的token名称是satoken，我们可以通过修改token-name配置，指定我们需要的token名称

sa-token:
  token-name: token

再次登录

sa-toekn.timeout 超时时间

超时时间，默认是三十天，单位是秒，我们来配置个5秒超时，验证一下是否好用

sa-token:
  token-name: token
  timeout: 5

执行登录，然后查看登陆状态

5秒后再次查询登陆状态

sa-toekn.activity-timeout 临时超时时间

说实话看到这个介绍我还是有点开心的，因为曾经开发过类似的业务，但是还有什么比框架本身就支持来得更舒服呢？把超时时间注释掉，加上把临时有效期设置为5s再测试一波。

先登录，再多次查询登录状态，不出意外的5s以后掉线了[泣不成声]，赶快看看文档，文档里写着：在每次直接或间接调用getLoginId()时进行一次过期检查与续签操作。想想也对，毕竟在需要身份认证的接口中每次访问都要获取用户Id的，没毛病，暂且先在检查登录状态接口获取一下ID进行返回，修改代码再测试。

// 查询登录状态，浏览器访问： http://localhost:9999/user/isLogin
@RequestMapping("isLogin")
public String isLogin() {
    return "当前会话是否登录：" + StpUtil.isLogin() + (StpUtil.isLogin() ? "登录的Id："+StpUtil.getLoginId() : "") ;
}

这次就没问题了，在不停地重新请求接口的过程中，没有发生掉线的情况

在5s无操作之后，再次刷新

这时候就正常掉线了，真的很方便。该功能测试完毕，修改成一个常用的超时时间，开始测试其他配置。

sa-toekn.is-concurrent 同账号并发登录（多地登录）

这个配置也是一个常用的配置，有些系统同一个账号同一时间只允许在一个设备上登录，有些系统则没有这样的限制，现在配置里增加：

sa-token:
  #  是否允许同一账号并发登录
  is-concurrent: true

再利用两个浏览器分别执行登陆，检查登录状态

可以看到两个浏览器都登录成功，并且得到了相同的token值，检查登录状态

也可以获取到相同的登录信息，我们修改配置为false，再次运行

sa-token:
  #  是否允许同一账号并发登录
  is-concurrent: false

首先分别执行登陆

再分别查看登陆状态

可以确定，首先登录的那个已经被挤下线了

sa-toekn.is-share 同账号并发登录是否共用Token

这个也是一个非常实用的功能，如果希望同账号在不同设备登陆时享有单独的超时时间、设备标签等，就可以不共用token，反之就可以公用token，保证账号一处登出，所有设备同时下线，增加安全性。

更多配置

官方文档提供详尽的配置项表格，有兴趣的可以去查看文档，可以说是非常实用了。