Безопасно ли использовать идентификаторы задач Celery в HTTP-запросах?

Я начинаю использовать Celery в веб-приложении на основе Flask для запуска асинхронных задач на стороне сервера.

Несколько ресурсов получают подресурс '/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, если задача все еще выполняется).

Идентификатор, который я возвращаю для действия, — это celery.result.AsyncResult.id.

Безопасно ли это? Какие проблемы возникают при передаче идентификаторов задач Celery напрямую публике?

Если нет, есть ли рекомендуемый способ? Предпочтительно тот, который позволяет избежать явного отслеживания состояния задач.


celery celery-task
person dev-zero    schedule 25.08.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Вы будете в порядке, используя идентификатор задачи. Celery использует функцию uuid Kombu, которая, в свою очередь, по умолчанию использует uuid4. uuid4 генерируется случайным образом, а не на основе MAC-адреса (каким является uuid1), поэтому он будет «достаточно случайным».

Единственным другим способом было бы иметь конечную точку API, которая возвращает статус всех запущенных задач для пользователя. то есть удалить любой идентификатор задачи. Но тогда вы уберете возможность запрашивать отдельную задачу. Другие варианты будут эффективно маскировать идентификатор задачи за другим случайным числом, поэтому у вас будет та же проблема с перебором.

Я бы порекомендовал просмотреть вопросы по UUID на Stack Exchange по безопасности (https://security.stackexchange.com/search?q=uuid). Некоторые из них, без сомнения, будут эквивалентны тому, что вы ищете.

person Lllama    schedule 26.08.2016