可以考虑写个

继承 dict, 复写 __setitem__

| 但是我的疑问来了。那么这个 key 是不是任何人拿到了都可以通过验证？服务端提前生成了 key，所以没办法在过期日期前让 key 失效？ 所以失效的办法只有更改服务端的加密算法，让所有的 key 都失效而达到目的？


鉴权的值只要拿到都是可以通过验证的。

需要在过期前让其失效，那么办法就是像 @justfindu 说的 做多一个 blacklist
但一般不要存 token 进去，而是解开后像校验日期一样，校验某个 unique key,

这里是为了防止某些人恶作剧，生成 N 个 token，然后可以塞爆。


----

一般也不改加密算法，你说的倒有可能是改 seed。
但一般不这么做。

其实没必要纠结形式。

鉴权 (authentication) 的本质是知道请求是谁，
这个过程大概就是 request - authentication - response。

你 request 方式是没关系的，你从 header 进来，从 cookie 进来，从 params 进来，从 body 进来，目的只有一个，就是让服务器可以知道你是谁。

比如你说
| 1.登录后，账号，密码（加密）放 cookie 里 [不安全不推荐]
你可以假设服务器有个函数为: auth_with_username_and_password(username, password) -> bool
只要为 true，那么证明账号密码都是对的，只要这一步成功，那么就把这个鉴权信息放在上下文 (context) 那么这个过程就可以继续传递下去

|2.登录后生成一个 sessionId 放到客户端 cookie 里。只放 session 的话 不保险（资源和重启服务），所以要 session + Redis

这个我感觉有些人云亦云了，
你可以当成是解耦的过程，
auth_with_username_and_password(username, password) -> str

这个 str 可以有 2 种返回方式，
一种直接通过 response 返回，你拿到 str 之后前端存到哪也是没关系的，反正用的时候带上；
一种是通过 set-cookie 的方式，直接把这个写进 cookie 里；

那么 auth 的方式就是通过
[auth_with_username_and_password, auth_with_session_id]

auth_with_session_id(session_id) -> bool

auth_with_session_id 这里怎么存都是没关系的，
你存数据库，存 redis，存本地文件都可以，只要拿得到并且有效就可以。

这个东西好处是，避免明码泄露账号密码，但 session 漏出去也是一样的。


| 3.jwt ???
一般说 有状态，无状态，这里你可以理解 jwt 无状态，是指
jwt 已经包含了主要的鉴权信息
jwt 的 j 也表明了是一个 json 结构，再做一层 decode 操作

这里跟 2 比的好处是，无论你 session 放哪，你去到服务器有一个查询的操作，
你用 jwt 的话，那么只需要解密+校验有效期就可以了。

那么 auth 的方式就是通过

auth_with_username_and_password(username, password) -> str

auth 方式可为
[auth_with_username_and_password, auth_with_token]

auth_with_token(token) -> bool

====

所以你可以把这个过程看成解耦 + 安全 + 优解。

至于用 redis 和 用其他去做，都是优化
你就算记在本子里，每次用户登录，你从本子找，然后发现对应上了，就通过，那么是一样的，无非用户需要等你慢慢找。
所以怎么判断，其实就是 f(x) 有没解的过程。

@victoriazy

哈哈哈，这个确实需要展开

抄类型。比如 flask 的时候，那时候很火抄了做个问答，类似知乎的，你也去抄，但我不知现在流行抄啥。


然后抄的过程，有几个学习点

- 看大家是怎么搬砖的，比如用到了什么框架，用到了什么第三方库，用到了什么特性；
- 看搬砖流程一般怎么搬，比如 git 怎么协作，比如前后端怎么配合，比如 bug 怎么调试
- 然后还有一个就是 web 入门比如简单一些点，要求你 crud 怎么操作，你要去的公司对你的要求怎样


然后怎么说呢，进这个地方做好心理准备，用心搬砖掏粪，没那么好搞，也不可能一上来那么多高新尖能让你搞。
还是要继续努力。

@victoriazy

抄两个项目看看吧。
当时我玩的时候，比较多是抄个 todo 和做个 web 之类

工作还是用 drf 省心，毕竟是搬砖。
而且转行做开发怎么说呢，舍得手脏吧，掏粪可以优雅，都没办法不沾。

@SbloodyS

哈哈哈，我之前荔湾现在天河，打电话和看网页，都是 1900+好像。

我回去再去问问，谢啦

| OS、计算机网络和数据结构与算法基本学的差不多了，题也刷过，可以说万事俱备
此话存疑

如果走 python web 的话，可以看下 django + django rest framework( https://www.django-rest-framework.org/)

drf + pg(mysql)
或者
flask + mongo
flask + mysql

这几种还是有机会做做

@SbloodyS

是啊，我这边也是小区，不过我看营业厅都是 2k 左右

@SbloodyS

广州电信 100m 这么便宜吗。。。请问哪里可以办

> 唐僧成佛历经了九九八十一难，

因慈悲故，不住涅槃

-----
> 为什么恶人放下屠刀就能立地成佛

因智慧故，不住轮回

@freakxx #47

错别字:
convert_gmt_to_local_time

covert -> convert

python

def covert_gmt_to_local_time(timezone, now=None)


函数直接写死的话，假如遇到上海，又得写一个，遇到广州又得写一个；

@shengchao #8

未免过于武断.


===========

可以考虑做一个计数器放在执行体里

65 = 13 * 5

做个 5 分钟的任务，

当 N % 13 = 0 执行

厄尔尼诺

@BingoXuan #6
习惯了 self 和 super 这一套后, 在 py 接受不来 this.

而且从设计来说，好的统一习惯总归是好的。

this 的指代是很不明确的，前几天还跟同事吐槽了以前一种很丑的 js 写法：
var that = this.

@fourstring
突然翻到这主题

这个是可以读写一致的，并且可以打开字段，

我之前写过几个版本的这玩意。

还写过递归的版本，反 Nested 存储到复层。


---------------

从源代码角度来说，serializer 也是一个 field，

你继承 PrimaryKeyRelatedField （ HyperlinkRelatedField ）后改写他的 to_internal_value 和 to_representation，就可以实现了你的需求。

字段调用大概长这样子
items = ObjectRelatedField(
...
serializer_class=ControlItemSerializer
)

实际上就是丢一个渲染的 serializer 进去 to_representation。

拆成 2 个部分

记录的话用信号机制，用 init 事先 copy （性能的话会有损耗）
搜索关键词 django signal field change
参考
https://stackoverflow.com/questions/36719566/identify-the-changed-fields-in-django-post-save-signal
https://stackoverflow.com/questions/1197674/actions-triggered-by-field-change-in-django


记录访问操作，考虑做一个中间件
流过 process request 或者 view request 做一下记录
搜索关键词 django middleware log
参考
https://djangosnippets.org/snippets/428/
https://stackoverflow.com/questions/862522/django-populate-user-id-when-saving-a-model/12977709#12977709

感觉可以试下这种方式

做一个 register decorator，然后可以指定 urlpatterns, 然后按照 path 的写法，在修饰器实现 path 注册。

然后类内部函数还是走 action 那套，或者同样实现的功能。

感觉整体会更漂亮一些。

@hollizhao #16

哈哈哈，作为 drf 吹，感觉还是要吹一波 django rest framework。