84669 人学习
152542 人学习
20005 人学习
5487 人学习
7821 人学习
359900 人学习
3350 人学习
180660 人学习
48569 人学习
18603 人学习
40936 人学习
1549 人学习
1183 人学习
32909 人学习
目前想了一个方案,不知道有没有类似的成熟方案.
1.用户第一次验证2.在指定token目录下创建一个以token值命名的文件.3.返回token给用户保存.4.客户端:通过判断URL200或404进行逻辑处理,服务端:通过判断文件是否存在进行逻辑处理.
想到的安全性设置是禁止爬虫爬该目录,监控用户对该目录的连接数防止暴力破解.请问这种方式有没有BUG及性能问题?或者有没有比这更好的解决方案?
光阴似箭催人老,日月如移越少年。
这个方案,请参见我的另一个回答:/q/10...
这个方案,虽然没有被当做一个标准,但是却是普遍在用的方案。缺点还是有的,比如:
如果生成的token太长,在GET的时候就要考虑是否超过GET请求长度限制(因为URL长度有限),但是太短的token又不能确保高唯一性和安全性
当然,token做用户令牌也不是安全的。如果在令牌过期之前,token被别人偷到了,他人就可以仿冒此用户进行操作而不需要登录。
如果要比较安全的方法,那就是用Session服务器对用户进行验证,不过Session跨域问题确实是个老生常谈的问题,而token的跨域完全不存在问题,只要能访问到接口,token是在请求数据里传过去的。所以个人观点是,只有在安全和易用的层面进行取舍了。当然也可以用其他的校验方式,比如JWT等等,但是这种方法更加繁琐(除非不用自己造轮子)。
1.客户端提交信息2.服务端检查信息的正确性,如果不合法登陆失败3.服务端利用算法生成token,并token存储在redis等高并发的数据库中,并设置过期时间4.服务端将token返回客户端5.客户端保存token6,客户端下次请求时,携带token,服务端验证token的有效性,有效则通过,无效则验证失败
这个方案,请参见我的另一个回答:/q/10...
这个方案,虽然没有被当做一个标准,但是却是普遍在用的方案。
缺点还是有的,比如:
如果生成的token太长,在GET的时候就要考虑是否超过GET请求长度限制(因为URL长度有限),但是太短的token又不能确保高唯一性和安全性
当然,token做用户令牌也不是安全的。如果在令牌过期之前,token被别人偷到了,他人就可以仿冒此用户进行操作而不需要登录。
如果要比较安全的方法,那就是用Session服务器对用户进行验证,不过Session跨域问题确实是个老生常谈的问题,而token的跨域完全不存在问题,只要能访问到接口,token是在请求数据里传过去的。所以个人观点是,只有在安全和易用的层面进行取舍了。当然也可以用其他的校验方式,比如JWT等等,但是这种方法更加繁琐(除非不用自己造轮子)。
1.客户端提交信息
2.服务端检查信息的正确性,如果不合法登陆失败
3.服务端利用算法生成token,并token存储在redis等高并发的数据库中,并设置过期时间
4.服务端将token返回客户端
5.客户端保存token
6,客户端下次请求时,携带token,服务端验证token的有效性,有效则通过,无效则验证失败