是像传统项目一样用session,还是将用户名密码发送到一个登录接口之后返回一个access_token,然后将这个access_token和用户uid的关系存入数据库或者缓存,每次请求的时候通过客户端携带的这个access_token来进行身份验证?
能不能分析分析两种方法的优劣?
我个人的看法是:前者开发起来会比较简单,直接取session即可。后者这种方式可以实现原生APP和网页公用一套后端接口。
是像传统项目一样用session,还是将用户名密码发送到一个登录接口之后返回一个access_token,然后将这个access_token和用户uid的关系存入数据库或者缓存,每次请求的时候通过客户端携带的这个access_token来进行身份验证?
能不能分析分析两种方法的优劣?
我个人的看法是:前者开发起来会比较简单,直接取session即可。后者这种方式可以实现原生APP和网页公用一套后端接口。
谢邀。上午在忙,没来得及回复,不好意思
既然你做的是前后端分离,那想必vue+node
作为前端项目,后端数据相关的业务操作是其他程序负责了。
所以node端主要是维持cookie session,保持用于登录状态,负责接口转发。那么后端业务域名可以做局域网的,不对外公开(如果不提供API给第三方),那么安全性已经上升很多了,不知道你们的场景是不是这样。
ok,那么你说的两种处理方案,其实也没有什么劣势优势。因为只有将session中的uid保证不会被恶意修改就好了,使用session
也挺好,持久化到mongodb
或者redis
,配合分布式负载均衡效果很棒的。
关于你说的两种方案:
session。 一般网站都会在请求的时候通过session判断是否登录什么的,这个cookie被模拟或者劫持,服务器就懵逼了,人家可以随意发请求修改数据了,任何用户的数据。所以如果使用session,一定要注意cookie的操作安全性,防止客户端可以修改cookie内容。至于优势:就是简单呗
token。 对于后端数据接口还是有必要的,这个安全判断交给后端也是合情合理,生产机制什么的完全让他们去做,你只需要登录获取token保存好就可以了,也没有多麻烦。安全上要比session高点。
但其实当别人把cookie模拟,token破解服务器一样懵逼。。。
大概说一下,我认为现在的用户安全认证无非就是为了两点:
识别是哪个用户,确认请求对号入座,不能因为a用户改了客户端uid
就修改了b用户的数据(简单举例)。
防止恶意并发请求的攻击。
不过建议使用session + token
,防止客户端攻击就好了。数据安全比什么都重要。
然后node端与后端都需要对恶意多请求
做防御,如果觉得有必要的话……
其实真要有人想搞你们,用什么都防不住。只有防住那些闲着蛋疼无聊手贱的人就好了……
你的这个问题解决方式有很多,但是具体还是看技术这块的架构。说一说我司的做法吧,我们每一个项目会有一个key,这个key是一段没有规律的字符串,然后不同的环境下key是不同的(例如开发环境,测试,生产等)。然后cookie,和session(我们有一套封装好的请求校验这块的js库),然后用这个库去封装好的方法去请求服务端,服务端还会进行校验,若果是这些东西不满足,那么会禁止它进行请求。(我们后台有一个统一的网关,我们并不是直接请求服务端,而是向这个网关发起请求,网关会处理什么负载均衡已经安全的处理)。也不知道是否能对你有帮助,提供给你参考一下吧!
10 回答11.1k 阅读
6 回答3k 阅读
5 回答4.8k 阅读✓ 已解决
4 回答3.1k 阅读✓ 已解决
2 回答2.6k 阅读✓ 已解决
3 回答5.1k 阅读✓ 已解决
5 回答1.9k 阅读
首先,先说结论,安全程度基本上都是一样的,cookie或者token被劫持了一样能伪造请求,所以需要结合实际场景判断那种方式更优
其次,要看你使用场景,是外包项目的话怎么简单怎么来,如果是自己练习或者公司项目,则要做对自己
有挑战的
,或者大家公认对公司项目高可用
,易扩展
的最后,其实原理都差不多,都是要携带必要的信息作为权限认证
使用session相当于在浏览器中存了cookie,每次发请求的时候检查cookie就行,负载均衡上面在入口分发请求的设备上面做鉴权就可以了,如果单台服务器就更简单了
token更偏向于客户端的用法,不同的是需要你把token换成uid,而session则是大部分编程语言自己来处理的
最后说说我司的做法,我司APP使用的是token,因为APP是编译的生成,对token的加密方法保护得很好
如果是网页则是先登录授权服务器,换取一个token,然后再带着这个token登录各个不同的服务项目,由各个服务自己使用该token想授权服务器验证,如果通过验证,在给各个服务独有的session或者token