- 主题:RESTful API是不是最好不要用cookie login?
虽然只是header当中的一个字段 理论上并不是严重的问题 但是需要先login一次才能获得authentication token 不算是严格的stateless了
--
FROM 110.23.10.*
多谢大神码着么多字
其实我问cookie是因为我的网页和xamarin(android+ios)要共用一部分API 不过xamarin的.net httpclient貌似自身不支持cookie的 所以对我自己的做法是不是有点非主流有点怀疑
我是半路出家 原本底子是vb.net 对数据的使用和理解比较路径依赖吧 习惯于.net entity framework + remote procedure call那套技术路线 所以搞nodejs还是造这种轮子
【 在 dhcn 的大作中提到: 】
: 这其实和stateless没啥关系,因为rest stateless主要说的restful操作的主数据部分API,根本和鉴权数据没啥关系。
: 其次cookie只是为浏览器缓存准备的特殊通信header,没有浏览器给你管cookie的情况下,你所谓的cookie实际是你自己管理存存储,你通信的时候放着直接的header不来,还要自己造个Cookie玩,那不成舍近求远了吗?
: 在RestfulAPI中,如果需要伺候浏览器代码,直接加个sessionmiddleware就完了,而且所有上面这一切都不用自己思考设计,因为Restful框架是有标准设计实现放在那儿,你所要做的只是理解清楚用对就行了。
: ...................
--
FROM 110.23.10.*
另外 我感觉nodejs全栈这个流派里 好像没有太主流的技术路线 各家用的东西貌似千差万别的 每次去npm上搜 同样的功能都有好多种实现
【 在 dhcn 的大作中提到: 】
: 这其实和stateless没啥关系,因为rest stateless主要说的restful操作的主数据部分API,根本和鉴权数据没啥关系。
: 其次cookie只是为浏览器缓存准备的特殊通信header,没有浏览器给你管cookie的情况下,你所谓的cookie实际是你自己管理存存储,你通信的时候放着直接的header不来,还要自己造个Cookie玩,那不成舍近求远了吗?
: 在RestfulAPI中,如果需要伺候浏览器代码,直接加个sessionmiddleware就完了,而且所有上面这一切都不用自己思考设计,因为Restful框架是有标准设计实现放在那儿,你所要做的只是理解清楚用对就行了。
: ...................
--
FROM 110.23.10.*
多谢指点
我原本也是想每个api请求都验证token 然后把token替换成新的 不过细想之后发现如果用户并发请求的话就会出bug了 所以只好在用户每次login时生成一个token一直用 但是每次api请求会换了一个随机密码加密 以便让token看起来每次都不一样 防止破解其中的过期时间
但是后来还是把过期时间保存在server端了
【 在 cnxs 的大作中提到: 】
: 我们处理方式是用户每次api请求都return一个cors token,所以我们每次都verify cors token是不是来自真实用户的请求
: 然后我们cookie就存用户id
: 每次api请求首先verify cors token是不是有效请求,然后check用户id是不是有效id,都通过了,你就可以处理api request了,当然这些东西都是加密过的
: ...................
--
FROM 110.23.10.*