按照项目需求构建好环境
使用redis自定义配置,使用@ConfigurationProperties注解时 idea弹出 Spring Boot Annotion processor not found in classpath
根据提示,按照官方文档添加以下依赖可解决
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-configuration-processor</artifactId>
<optional>true</optional>
</dependency>
再次运行刚配置好的redis,通过jedis
发现报错...
检查了半天代码,网上找了下方式都不太对..忽然想到,阿里云的安全组端口没开放...
加上配置好的端口就行,默认的
重新运行,可以了
数据库设计
1.第一个md5 防止用户的密码在网络上暴露
2.第二个md5尽可能避免数据库的密码通过彩虹表反推破解
数据库里面存的是做了两次MD5的用户密码与其对应的salt值
问题引用：
第二次MD5所用的随机saltDB为什么要保存在数据库里？
当数据库被侵入，做MD5之后的密码和saltDB一起被盗的话，用户密码不就泄露了吗？
但是如果不保存这个随机的saltDB，下次用户登录的时候不就没法和数据库保存的密码进行校验了吗？
问题思考：
实际上做MD5也不是绝对安全的，但是我们可以使得破解的难度指数级增长。md5是不可逆的，不能反向解密的，网上所谓的“解密”都是把“加密”结果存储到数据库再比对的只能暴力破解，即有一个字典，从字典中读取一条记录，将密码用加salt盐值做MD5来对比数据库里面的值是否相等。
因为好事者收集常用的密码，然后对他们执行 MD5，然后做成一个数据量非常庞大的数据字典，然后对泄露的数据库中的密码进行对比，如果你的原始密码很不幸的被包含在这个数据字典中，那么花不了多长时间就能把你的原始密码匹配出来，这个数据字典很容易收集，假设有600w个密码。坏人们可以利用他们数据字典中的密码，加上我们泄露数据库中的 Salt，然后散列，然后再匹配。
但是由于我们的 Salt 是随机产生的，每条数据都要加上 Salt 后再散列，假如我们的用户数据表中有 30w 条数据，数据字典中有 600w 条数据，坏人们如果想要完全覆盖的话，他们就必须加上 Salt 后再散列的数据字典数据量就应该是 300000* 6000000 = 1800000000000，所以说干坏事的成本太高了吧。但是如果只是想破解某个用户的密码的话，只需为这 600w 条数据加上 Salt，然后散列匹配。可见** Salt 虽然大大提高了安全系数，但也并非绝对安全。**
实际项目中，Salt 不一定要加在最前面或最后面，也可以插在中间嘛，也可以分开插入，也可以倒序，程序设计时可以灵活调整，都可以使破解的难度指数级增长。
