在 HTTP 请求中使用 Celery 任务 ID 是否安全？答案

【问题标题】：Is it safe to use Celery task IDs in HTTP requests?在 HTTP 请求中使用 Celery 任务 ID 是否安全？
【发布时间】：2016-08-25 09:27:53
【问题描述】：

我开始在基于 Flask 的 Web 应用程序中使用 Celery 在服务器端运行异步任务。

一些资源获得一个“/action”子资源，用户/客户端可以向该子资源发送一个 POST，其中包括一个指定操作的 JSON 正文，例如：

curl -H "Content-Type: application/json" -X POST \
  -d '{"doPostprocessing": { "update": true}}}' \
  "http://localhost:5000/api/results/123/action"

他们收到带有标题的202 ACCEPTED 响应

Location: http://localhost:5000/api/results/123/action/8c742418-4ade-474f-8c54-55deed09b9e5

他们可以轮询以获得最终结果（如果任务仍在运行，则可以获取另一个 202 ACCEPTED）。

我为该操作返回的 ID 是 celery.result.AsyncResult.id。

这样做安全吗？将 Celery 任务 ID 直接传递给公众时会产生什么样的问题？

如果没有，有推荐的方法吗？最好是避免必须显式跟踪任务状态的一种。

【问题讨论】：

【解决方案1】：

您可以使用任务 ID。 Celery 使用 Kombu 的 uuid 函数，该函数默认使用 uuid4。 uuid4 是随机生成的，而不是基于 mac 地址（uuid1 是），所以会“足够随机”。

唯一的另一种方法是拥有一个 API 端点，该端点为用户返回所有正在运行的任务的状态。即删除任何任务 ID。但是您随后将删除查询单个任务的能力。其他选项将有效地将任务 ID 隐藏在不同的随机数后面，因此您将遇到相同的蛮力问题。

我建议您查看有关 UUID 问题的安全堆栈交换 (https://security.stackexchange.com/search?q=uuid)。其中一些无疑与您正在寻找的内容相同。

【讨论】：