都怪 emule 死了！

@rayingecho
就是无法撤销无法更新呗,表面上你可以通知客户端换 token,但这只对正常处理的客户端有效啊,别人非要保留之前的 token 继续拿来用,服务端也认为是合法的

比较好的做法是不重要授权信息直接存 token 的 playload,重要的还是得存在服务端每次校验

或者 xx 次操作后重新读取授权信息

本质上是认为在不知道服务端加密 key 的情况下你无法伪造出合法 token,所以服务端只用对 token 和服务端的加密 key 进行运算就能判断 token 所带信息的真伪

和 session 对比最大优点是 token 的校验不需要读取存储设备,也不需要重新鉴权,高并发下优势很大
缺点是不能提前过期 token 以及在 token 过期时间内改变 token 的内容.

建议看下 fernet token 的的做法, 理解下 fernet token 为什么要轮询换加密

用 jsonschema 来处理 request.args,这样就不用写一堆判断

还有不要用变量 req 来等于 request.args,req 容易误解

@chaleaochexist

我说的不一定对 但是说一下
首先你要知道 openstack 迭代了好多版本,很多代码是为了兼容老版本,方便升级写的,自己设计可以跳过这些不必要的设计


dbapi 这个层, 我猜是因为 openstack 对数据库的操作没做什么优化,性能其实挺差的,很多问题都没处理.比如说什么锁的问题,高并发问题都没考虑过

加了一层 dbapi(一方面可以兼容原有的本地写方式,一方面应该是处于数据库性能上的考虑),这样就相当于数据库中间件客户端了, 有 dbapi 在扩展性、向上版本兼容性上就好很多

nova/neutron 的数据库配置不走本地的话, 是通过 rpc 发到专门写数据库的程序的
由于 openstack 的 rpc 统一用 mq 做的, 自己做的话,这部分不应该走 mq,应该自己实现专门的中间件
如果你的数据库操作不需要转发出去,直接当前进程和数据库通信的话,这层就没必要了

封装 object 也是为了版本迭代和扩展性考虑的,好像思路比较类似 java 的 dao 层？
因为 openstack 的 rpc 可以设置专门的序列化方式, 所以可以轻松的把 json 转化为对应的 python object （对应上封装的那层 object ）对象,然后这些 object 就可以直接转为对应数据库操作了.这玩意是一整套的实现来的

如果自己的程序不需要迭代更新兼容,这一层其实也没有必要,直接拿 json 发过来数据进行数据库操作就行了

@chaleaochexist

因为是好多人写的 每个组件都是不同的一群人写的

所以风格完全不一样啊

为啥不整个抄 openstack 那套捏

连 http 服务都一起啊....

我都写完 APP 然后都没再碰两个月了 还没见啥 flutter 的群

话说 有啥 python 的工作啊？

分布式 一定有
1 仲裁能力
2 >=3 的参与仲裁成员
3 快速的同步
4 仲裁投票
5、6、7....等等等等

讲到底还是要懂 Paxos 那套原理

一 redis 搞分布式锁,意思意思就行了.....

@Cbdy

安全行为是浏览器实现的,有用但是靠不住的

限制只能靠后端自己, so.....

@mrbeannnnn

method 只是个规范 不涉及任何安全问题 安全问题存在于实现代码中

iis6 有问题也是 iis6 自己的 http 实现有问题
他代码里的的 put delete 相关代码有问题不带表 put delete 本身有安全问题

method 对 http 服务器来说只是一个字段,具体怎么处理看你 http 服务里的代码里怎么写 然后再到业务代码处理

这些你只要完整的看过一遍 http 服务代码就懂了

至于前端什么的不支持 put 和 get 也是没关系的,标准的 http 服务框架代码都支持 method 重定向

哦想起来了 我从 pip 上下载下来 本地装的 2333

自打包 rpm 党飘过 压根不怕
...等等 我 window 上没 msi 包只能 pip 的咋办 233333

所以我压根就不碰国内的大部分软件 开源也一个卵样

flutter ....块得很

随便看了下 1 楼的库, 就代码行数上来看太简单了很有可能 json 解析并不靠谱

应该不如 jsonlint

虽然我都没认真读过里面代码, 但是 jsonlint 原理上屌不少 23333

用 jsonlint 加 long.js 解决

这样 json 解析的时候 超过长度的会返回的就是一个 Long 对象

数字处理会方便点...