一：问题描述
目前的系统是基于若依框架开发的一个系统，这个系统划分了两个应用，分别是用户端应用和管理端应用，都是有独立的前端页面和后端服务。用户端应用和管理端应用除了war包是独立的，war所依赖的其他jar包基本差不多。
目前存在的问题是，针对管理端war包暴露的接口通过postman测试始终是报如下错误：
{
"msg": "请求访问：/system/user/test，认证失败，无法访问系统资源",
"code": 401
}但是用户端应用暴露的接口通过postman测试一直是ok的。真是非常奇怪的一件事情。
二：问题分析
- 首先是多次对证失败的接口进行postman执行测试，依然是不通过的
- 其次对该接口换种别的写法，也是认证不通过。
- 接下来换成别的接口进行测试，还是不通过。
- 于是分析，目前验证的方式始终是在本地Dev环境测试出现的问题，在管理台上接口确实正常可以访问的。所以甚是奇怪。
- 既然排除是代码的问题，而且又是不同环境结果不同，那么就开始思考那可能是环境配置的问题。
- 于是开始坚持项目工程的环境配置文件，发现如下情况：
\src\main\resources目录下有四个配置文件来区分不同环境
基础配置：application.yml
本地环境application-dev.yml
测试环境：application-sit.yml
生产环境：application-prod.yml
接下来发现application.yml配置了
# token配置
token:
# 令牌自定义标识
header: Authorization
# 令牌密钥
secret: abcdefghijklmnopqrstuvwxyz
# 令牌有效期（默认30分钟）
expireTime: 30
接下来发现application-dev.yml没有配置token，application-sit.yml配置token了，但配置的secret与application.yml是不一样的。
看到这个问题突然想起来了问题的原因和自己验证的过程。原来在验证的过程中往Postman贴的token传每次都是从Sit环境的管理台拷贝过来的，但是本地启动的是Dev环境，造成了使用测试环境的token去dev环境取认证，由于token的secret不一致，明显是验证不通过的。
三：解决方案：
将application-dev.yml 与 application-sit.yml的token的秘钥 改成一致就可以了。
四：问题总结：
当初对不同的环境划分不同的配置文件，是另外一个同事做的，当时他是按照他之前项目的经验和习惯落实到我的这个系统上的。
当时我给他讲划分配置文件的原则是公共的配置放到application.yml中，不同环境的分别放到各自的配置中，保持每个配置项个数要一致。那个时候他给我讲，如果是application-dev.yml、application-sit.yml等配置与application.yml重复配置项，那么会自动覆盖掉的。
目前遇到的这个问题就是因为 application-sit.yml 配置了token项，但application-dev.yml没有配置，由于的token的secret的值不一致，引出了的问题。
所以在相关配置、功能设计上一定要做到职责独立、不重复以及清晰，不一定非得使用多么高级的功能。
