- 主题:RESTful API是不是最好不要用cookie login？
虽然只是header当中的一个字段 理论上并不是严重的问题 但是需要先login一次才能获得authentication token 不算是严格的stateless了
--
FROM 110.23.10.*
这其实和stateless没啥关系,因为rest stateless主要说的restful操作的主数据部分API，根本和鉴权数据没啥关系。
其次cookie只是为浏览器缓存准备的特殊通信header，没有浏览器给你管cookie的情况下，你所谓的cookie实际是你自己管理存存储，你通信的时候放着直接的header不来，还要自己造个Cookie玩，那不成舍近求远了吗？
在RestfulAPI中，如果需要伺候浏览器代码，直接加个sessionmiddleware就完了，而且所有上面这一切都不用自己思考设计，因为Restful框架是有标准设计实现放在那儿，你所要做的只是理解清楚用对就行了。
给你推荐两本书：《ESTful Web Services Cookbook中文版》、《RESTful Web APIs中文版》
然后把java语言的Jersey或者DjangoRestFramework之类的框架文档看一遍，基本也就没啥问题了，用框架不仅可以让你少实现轮子，主要是直接学会框架包含的成熟的设计方式。
【 在 facilitator 的大作中提到: 】
: 虽然只是header当中的一个字段 理论上并不是严重的问题 但是需要先login一次才能获得authentication token 不算是严格的stateless了
--
修改:dhcn FROM 111.196.4.*
FROM 111.196.4.*
多谢大神码着么多字
其实我问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请求都return一个CSRF token，所以我们每次都verify CSRF token是不是来自真实用户的请求
然后我们cookie就存用户id
每次api请求首先verify CSRF token是不是有效请求，然后check用户id是不是有效id，都通过了，你就可以处理api request了，当然这些东西都是加密过的
这个当然是stateless的啊，因为authentication过程和api处理过程是分开的，你共享api完全没问题的
【 在 facilitator 的大作中提到: 】
: 多谢大神码着么多字
: 其实我问cookie是因为我的网页和xamarin(android+ios)要共用一部分API 不过xamarin的.net httpclient貌似自身不支持cookie的 所以对我自己的做法是不是有点非主流有点怀疑
: 我是半路出家 原本底子是vb.net 对数据的使用和理解比较路径依赖吧 习惯于.net entity framework + remote procedure call那套技术路线 所以搞nodejs还是造这种轮子
: ...................
--
修改:cnxs FROM 115.70.49.*
FROM 115.70.49.*
多谢指点
我原本也是想每个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.*
token每次都变吧？
Server端存token在redis上吗？如果是的话感觉应该先校验用户id啊，多谢
【 在 cnxs 的大作中提到: 】
: 我们处理方式是用户每次api请求都return一个CSRF token，所以我们每次都verify CSRF token是不是来自真实用户的请求
: 然后我们cookie就存用户id
: 每次api请求首先verify CSRF token是不是有效请求，然后check用户id是不是有效id，都通过了，你就可以处理api request了，当然这些东西都是加密过的
: ...................
--
FROM 124.126.144.*
如果是相同的信息，理论上用相同的加密方式，token是不会变的。所以需要你放入一些会改变的信息，如过期时间等，这样token才会不一样。
我看过一篇很长的写jwt的文章，理论上token是不用储存的，因为token自己可以含有非常多的信息。比如可以在用户表储存个登陆时间，然后生成token时放进去。然后验证token时，用token的id查到用户，证明用户存在。然后比对最后登陆时间等信息，证明是有限请求。
【 在 sitepenfan () 的大作中提到: 】
: token每次都变吧？
: Server端存token在redis上吗？如果是的话感觉应该先校验用户id啊，多谢
:
: 【 在 cnxs 的大作中提到: 】
--
修改:dagon FROM 39.177.181.*
FROM 39.177.181.*
看了半天，你这里问的问题和另一个帖的问题。我说说我的理解。
第一种就是另一个帖子中回复生成独一无二的token，并在服务器中保存。他提出token中不包含任何真实数据。这种做法是可行的，就像你说的每次生成随机密码加密。我个人理解你们这种加密是不可逆的，需要在服务端存储token并进行比对。
第二种是所谓的jwt模式，json web token。将信息以json的形式储存到token中，比如用户id和过期时间等。这种token是可逆的，在服务器上配置好公钥和私钥，可以将用户的token揭秘成json格式的信息。然后去比对用户的id是不是真实的，token有没有过期。这种token是不用储存在服务器的数据库或者redis中的。过期时间也不用在服务器端储存。你说的破解token的有效时间的问题。如果对方没有你的私钥，理论上他修改的token你这里解密不了，因此可以判断token被修改了。
【 在 facilitator () 的大作中提到: 】
: 多谢指点
:
: 我原本也是想每个api请求都验证token 然后把token替换成新的 不过细想之后发现如果用户并发请求的话就会出bug了 所以只好在用户每次login时生成一个token一直用 但是每次api请求会换了一个随机密码加密 以便让token看起来每次都不一样 防止破解其中的过期时间
:
--
修改:dagon FROM 39.177.181.*
FROM 39.177.181.*