【问题标题】：User authentication: prepare vs get_current_user in tornado用户身份验证：在龙卷风中准备 vs get_current_user
【发布时间】：2016-08-12 21:19:41
【问题描述】：
我需要通过 Tornado 上运行的应用程序中的 cookie 对用户进行身份验证。我需要解析 cookie 并使用 cookie 内容从数据库加载用户。在查看Tornado RequestHandler documentation 时，有两种方法：
- 通过覆盖
RequestHandler 类的prepare() 方法。
- 通过覆盖
RequestHandler 类的get_current_user() 方法。
我对以下陈述感到困惑：
注意prepare() 可能是协程，而get_current_user() 可能
不是，所以如果加载用户需要后一种形式是必要的
异步操作。
我不明白其中的两件事：
文档中说get_current_user() 可能不是协程是什么意思？ 可能不是在这里是什么意思？要么可以是协程，要么不能。
如果需要异步操作，为什么需要 latter 形式，即get_current_user()？如果prepare()可以是协程而get_current_user()可能不是，那么prepare()不应该用于异步操作吗？
我非常感谢任何帮助。
【问题讨论】：
标签：
python
python-3.x
tornado
coroutine
python-asyncio
【解决方案1】：
这里，“可能不是协程”的意思是“不允许成为协程”或“不得成为协程”。使用的语言令人困惑，可能应该改为说“不得”。
同样，文档令人困惑：在这句话中首先提到了prepare()，但在这句话之前有两个例子，get_current_user 是第一位的。 “后者”指的是第二个例子，它使用了prepare()。
总之，不管你是否需要协程，它总是可以覆盖prepare() 并设置self.current_user。如果你不需要协程来获取当前用户，你可以覆盖get_current_user()，它会在第一次访问self.current_user 时自动调用。你选择哪一个并不重要。您可以使用对您来说更自然的任何一种。 （我们有两种不同方法的原因是 get_current_user() 比较老，但我们不得不为协程使用不同的方法）
【解决方案2】：
1
获取当前用户的推荐方法是使用RequestHandler.current_user 属性。该属性实际上是一个函数，如果设置则返回RequestHandler._current_user，否则尝试通过调用get_current_user来设置。
因为current_user 是一个属性——它不能被产生，因此get_current_user 不能是协程函数。
当然可以，读取 cookie 并调用 db，以 get_current_user 验证用户身份，但只能以阻塞（同步）方式。
2
在你引用的doc中，后一个例子就是prepare的那个。