背景
由于注册的网站越来越多,各个网站对于密码的复杂度要求各有不一,为了便于随时随地可以查看各个网站的账户和密码,故开发自定义版线上密码本。
问题1
设计之初也是想将密码以加密的形式从网站上展现,获取明文时加一些验证。但是发现密码可以加密,但是后台无法解密,本地windos环境正常加密解密。根据资料显示,是由于windows环境与linux环境导致的。所以先取消加密显示,后期研究再加上。
后台解密报错
avax.crypto.BadPaddingException: Given final block not properly padded
原因分析
private static SecretKeySpec getSecretKey(String password) {
//返回生成指定算法密钥生成器的 KeyGenerator 对象
KeyGenerator kg = null;
try {
kg = KeyGenerator.getInstance(KEY_ALGORITHM);
SecureRandom secureRandom = SecureRandom.getInstance("SHA1PRNG");
secureRandom.setSeed(password.getBytes());
//AES 要求密钥长度为 128
kg.init(128, secureRandom);
//生成一个密钥
SecretKey secretKey = kg.generateKey();
return new SecretKeySpec(secretKey.getEncoded(), KEY_ALGORITHM);// 转换为AES专用密钥
} catch (NoSuchAlgorithmException ex) {
log.error(ex.toString());
}
return null;
}
SecureRandom 实现完全随操作系统本身内部状态,除非调用方在调用 getInstance 方法之后又调用了 setSeed 方法;该实现在 windows 上每次生成的 key 都相同,但是在 solaris 或部分 linux 系统上则不同。
大问题
前端页面模板是vue框架写的,我从github pull 下来修改使用的。
问题1.项目打包后通过nginx部署,访问后发现登录返回404。nginx需要修改以下配置解决。
location / {
try_files $uri $uri/ /index.html; #---解决页面刷新404问题
}
问题2.解决404后在登录请求时反馈405 not allowed错误,访问被nginx拦截不被允许。因为这里请求的静态文件采用的是post方法,nginx是不允许post访问静态资源,所以nginx需要修改以下配置解决。
location / {
try_files $uri $uri/ /index.html; #---解决页面刷新404问题
error_page 405 =200 @405; #405页面处理
}
location @405 {
proxy_pass http://ip:端口$request_uri ; # 你的后台接口ip和port
resolver 114.114.114.114; #解决nginx no resolver defined to resolve问题
}
问题3.登录时后台返回jwt异常
io.jsonwebtoken.MalformedJwtException: JWT strings must contain exactly 2 period characters. Found:0
原因分析
由于前台项目npm run serve 时未报错,正常使用,但是npm run build 打包后到服务器就报这个错,只怀疑哪里配置有问题,代码应该没问题。后询问前端朋友发现,vue的路径代理只有开发时生效,听到这,我滴个亲娘欸。
module.exports = {
lintOnSave: false,
devServer: {
port: process.env.NODE_ENV == "production" ? 8000 : 9000,
// port:8080,
proxy: {
'/api': {
target: process.env.VUE_APP_URL,
// 允许跨域
changeOrigin: true,
ws: true,
pathRewrite: {
'^/api': ''
}
}
}
}
}
页面请求时带的有api/xxxx 这个前缀路径被后台拦截验证token,实际登录页面没有token,导致验证解析失败。因此,需要在nginx中配置页面转发。
location /api/{
proxy_pass http://ip:port/; #后台接口地址
resolver 114.114.114.114;
}
将请求路径上的/api/地址换掉,到这部署的系统正常登录。
问题4.redis中token莫名其妙消失
登录系统后使用不到一分钟我的token就失效了,我后台设置的30分钟,问题出在redis上,看了下redis上key的ttl正常,key在ttl未结束之前莫名其妙被清空了,多了个未知的key,起初对未知的key也没起疑心,专去研究为啥自己的key会丢失。通过redis info,未发现端倪。又通过info commandstats,发现有flushdb的命令执行过,但实际我没有执行过。通过monitor监控到,我的redis一直在被操作,他们的脚本执行完就flushdb一下,到此,确定redis是被攻击了。部署的redis的端口是默认的,密码也没有,被别有用心之人盯上了。
3 条评论
独特的构思和新颖的观点,让这篇文章在众多作品中脱颖而出。
跨文化对比分析视角值得深入探索。
文章深入浅出,既有深度思考,又不乏广度覆盖,令人叹为观止。