APP登陆方案设计之服务器（一）

上半年写了几个项目，有已完成的、半路夭折的。均由没我帅的一个CTO指导下进行，服务器使用nutz框架搭建，个人用起来感觉还是不错的，有想要尝试的筒子，可以去看我的另一篇博客：《使用IntelliJ IDEA 2017.1配置Nutz开发JavaWeb》。 现在简单总结一下这段时间的收获吧。

一、概述

本片博客将会总结以下几点内容：

登陆过程中密码加密、储存、传输 多端登录

二、密码问题

密码，对于每个人都是在熟悉不过的陌生人了，因为自己设置的密码总会忘记，当然这里我们讨论的是：项目里的密码需要怎么处理。

1. 加密：加密算法有很多，有比较简单的可解密的hash加密，不可逆的MD5加密，还有加盐(salt)加密。当然为了安全性，会考虑使用加盐之后进行不可逆的加密。但是在我的项目中，比较常用的是加盐后可解密的加密方法。（对于盐的问题在后面补充） 2. 传输：在登录时，我们只需要传递用户名、密码。同样在传输的过程中，我们的请求可能被截获，所以传输过程中的密码同样不能使用明文，即在客户端需要对密码进行加密，然后进行传输。 3. 储存：服务器的数据库同样有着被攻击的可能，所以我们数据库中储存的密码同样不会是明文，这就意味着开发者实际上并不知道用户的密码。 补充：这里对盐进行补充。

“加盐”即为计算机密码加密中常用的”add salt”，一般用于在原密码后面追加一些无关字符后在进行不可逆加密（例如MD5）以便增强安全性

这是百度百科对于加盐的解释。为了保证足够的安全性，我们对每一个用户，产生一个独一无二的盐并与用户绑定。为了保证盐的安全性，我们可以将用户的用户名使用某种加密算法加密后的值作为盐。这样的好处在于我们在向服务器传递信息时避免了传递盐的信息。

三、多端登陆问题

多端登陆，其实很好理解，就是同一个账号不能在多个客户端登陆。但是，这个问题对于一年前的我是一个比较复杂的问题，当时的一个项目并未实现限制用户多端登陆的功能，后来在CTO的指导下，理解并能够自己完成避免多端登录，也是很开心的。

解决：使用accessKey（下文称ak）。每次用户请求服务器时（注册登陆除外），必须携带ak，使用ak辨识发送请求的你是谁。