APP登陆方案设计之服务器(一)
2017-07-11 20:34
155 查看
上半年写了几个项目,有已完成的、半路夭折的。均由没我帅的一个CTO指导下进行,服务器使用nutz框架搭建,个人用起来感觉还是不错的,有想要尝试的筒子,可以去看我的另一篇博客:《使用IntelliJ IDEA 2017.1配置Nutz开发JavaWeb》。 现在简单总结一下这段时间的收获吧。
一、概述
本片博客将会总结以下几点内容:登陆过程中密码加密、储存、传输
多端登录
二、密码问题
密码,对于每个人都是在熟悉不过的陌生人了,因为自己设置的密码总会忘记,当然这里我们讨论的是:项目里的密码需要怎么处理。
1. 加密:加密算法有很多,有比较简单的可解密的hash加密,不可逆的MD5加密,还有加盐(salt)加密。当然为了安全性,会考虑使用加盐之后进行不可逆的加密。但是在我的项目中,比较常用的是加盐后可解密的加密方法。(对于盐的问题在后面补充)
2. 传输:在登录时,我们只需要传递用户名、密码。同样在传输的过程中,我们的请求可能被截获,所以传输过程中的密码同样不能使用明文,即在客户端需要对密码进行加密,然后进行传输。
3. 储存:服务器的数据库同样有着被攻击的可能,所以我们数据库中储存的密码同样不会是明文,这就意味着开发者实际上并不知道用户的密码。
补充:这里对盐进行补充。
“加盐”即为计算机密码加密中常用的”add salt”,一般用于在原密码后面追加一些无关字符后在进行不可逆加密(例如MD5)以便增强安全性
这是百度百科对于加盐的解释。为了保证足够的安全性,我们对每一个用户,产生一个独一无二的盐并与用户绑定。为了保证盐的安全性,我们可以将用户的用户名使用某种加密算法加密后的值作为盐。这样的好处在于我们在向服务器传递信息时避免了传递盐的信息。
三、多端登陆问题
多端登陆,其实很好理解,就是同一个账号不能在多个客户端登陆。但是,这个问题对于一年前的我是一个比较复杂的问题,当时的一个项目并未实现限制用户多端登陆的功能,后来在CTO的指导下,理解并能够自己完成避免多端登录,也是很开心的。
解决:使用accessKey(下文称ak)。每次用户请求服务器时(注册登陆除外),必须携带ak,使用ak辨识发送请求的你是谁。
相关文章推荐
- 网络游戏 贸易时代的总结(一)--总体设计和登陆服务器
- 基于MPEG-4的嵌入式网络视频服务器的设计方案
- linux下两台服务器文件实时同步方案设计和实现
- linux下两台服务器文件实时同步方案设计和实现
- 一个最小的物联网系统设计方案及源码——与服务器通讯
- 贸易时代的总结(一)--总体设计和登陆服务器
- 常见多线程与并发服务器设计方案举例
- 网游服务器通信架构的设计方案
- 网游服务器通信架构的设计方案
- 5种实用App导航菜单设计方案
- 多服务器游戏单点登陆设计思路
- 总体设计和登陆服务器 [游戏服务器的设计思路 转]
- Comet服务器设计方案
- 总体设计和登陆服务器 [游戏服务器的设计思路 转]
- Yahle 的服务器设计方案!
- 消息中心及监控服务器设计方案
- 魔兽世界的登陆服务器设计
- 网游服务器方案设计与配置推荐
- 常见多线程与并发服务器设计方案举例
- linux下两台服务器文件实时同步方案设计和实现