更好的对象转字典

一. 方便但不完美的__dict__ 对象转字典用到的方法为__dict__. 比如对象对象a的属性a.name='wk', a.age=18, 那么如果直接将使用a.__dict__获得对应的字典的值为: {name: 'wk', aget:18}, 很方便, 但是也存在一些限制. 其不完美之处在于: 比如: class A(object): name = 'wukt' age = 18 def __init__(self): self.gender = 'male' ...

flask: 內置HttpException的rest风格改进

在api的设计中, 无论异常还是正常数据均需要服务器以json的格式返回, 为了对异常的统一管理, 同时为了后续更加方便的返回和验证数据, 我们自定义异常返回类. 设计异常数据的返回格式为: { "error_code": 999, "msg": "sorry, we make a mistake", "request": "POST /v1/client/register" } 异常值分别代表: 999 未知错误 1006 客户端错误 1007 服务器错误 ...

JWT vs Session

一. session 1.1 session对于服务器的开销 在传统的用户登录认证中,都是采用session方式。用户登录成功,服务端会保证一个session,当然会给客户端一个sessionId,客户端会把sessionId保存在cookie中,每次请求都会携带这个sessionId。cookie+session这种模式通常是保存在内存中,而且服务从单服务到多服务会面临的session共享问题,随着用户量的增多,开销就会越大 1.2 session对于服务扩展性的限制 用户认证之后,服务端做认证记录,如果认证的记录被保存在内存中的话,这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源,这样在分布式的应用上,相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。 1.3 session+cookie认证方式存在的风险 CSRF: 因为是基于cookie来进行用户识别的, cookie如果被截获,用户就会很容易受到跨站请求伪造的攻击。 二. jwt(json web token) jwt的认证方式只需要服务端生成token,客户端保存这个token,每次请求携带这个token,服务端认证解析就可。 2.1 jwt生成的流程 客户端使用用户名和密码请求服务器 服务器验证后返回一个jwt 客户端存储jwt, 每次请求都会携带这个jwt 服务器验证jwt, 并返回数据 ...

flask工作原理图

整体过程   一个请求进入flask框架后, flask会首先实例化一个Request Context封装了这次请求的相关信息(Request), 然后将请求上下文推入栈_request_ctx_stack(这是LocalStack的一个实例).   在RequestContext对象入栈之前会检查App Context对应栈栈顶的元素, 如果不是当前的app, 则会先将app推入. 因此如果在一个请求中使用(注意是在请求中)使用current_app是不需要手动push的.   current_app取得是_app_ctckx_stack 的栈顶元素中的app属性, 这个属性就是我们自己创建的app=Flask(__name__), 如果栈顶为空,则提示unbound, 同样的request指的是_request_ctx_stack的栈顶对应对象, 当一个请求结束的时候会出栈.   Local 与 LocalStack: werkzeug, LocalStack作为线程隔离对象栈的基本特性 其他 手动压栈和出栈 如果要在没有请求的情况下使用核心对象需要手动push和pop, 一个例子 ctx ...

带有参数的装饰器

1. 函数带多个参数 # 普通的装饰器, 打印函数的运行时间 def decrator(func): def wrap(*args, **kwargs): start_time = time.time() res = func(*args, **kwargs) end_time = time.time() print('运行时间为', end_time-start_time) return res return wrap ...

我们立足于美利坚合众国,对全球华人服务,受北美法律保护