Mopidy: Отсутствует заголовок ответа CORS для статических файловых ресурсов

К сожалению, заголовок Access-Control-Allow-Origin допускает только одно значение. Это становится немного сложнее, когда мы хотим поддерживать несколько значений из нашего настроенного списка:

Для ограничения возможных значений Access-Control-Allow-Origin набором разрешенных источников требуется код на стороне сервера для проверки значения заголовка запроса Origin, сравнения его со списком разрешенных источников, а затем, если значение Origin находится в список, чтобы установить значение Access-Control-Allow-Origin на то же значение, что и значение Origin.

И это даже хуже, потому что, насколько я понимаю, вы не можете полагаться на то, что они являются заголовком запроса Origin, если это не запрос CORS . И вы также не можете полагаться на наличие заголовка Referer ни для каких запросов HTTPS (который был бы альтернативным заголовком для использования). Это то, что привело к довольно сложному коду защиты CSRF, который гарантирует, что предполетный CORS танцует (примечание: я думаю, что с тех пор это изменилось, и все POST-сообщения браузера теперь получают заголовок Origin?). Сомневаюсь, что мы хотим этого здесь.

Поскольку StaticFileHandler имеет дело только с «безопасными» запросами GET, может быть, можно просто установить заголовок ответа «Access-Control-Allow-Origin: *»?

Если подумать об этом подробнее (несмотря на нежелание), можно с уверенностью сказать, что любой браузер, заинтересованный в соблюдении политики CORS, отправит заголовок Origin. Таким образом, мы можем просто условно выполнить check_origin() на основе установленного заголовка Origin, а затем, если разрешено, скопировать значение заголовка в заголовок ответа Access-Control-Allow-Origin, как обычно. Если нет заголовка Origin, наше поведение не изменится.

Думая об этом больше (несмотря на нежелание)

Мне жаль. :не вижу зла:

Итак, что же такого особенного в статических активах? Почему мы не можем просто повторно использовать всю уже существующую классную логику. Я имею в виду, что все проверки исходного заголовка и т. Д. Уже есть, если я не ошибаюсь. Разве мы не можем использовать его для условной установки заголовков? : мышление:

Только запросы GET и политика CORS не то же самое, что защита CRSF для «небезопасных» методов с побочными эффектами, такими как POST. Это разные проблемы, и их решение не одно и то же.

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

Было ли мое последнее сообщение осмысленным? Вы хотите применить исправление, или я должен добавить его в список дел?

Да, это имеет смысл. : смайлик:

Было бы здорово, если бы вы могли добавить его в список. Хотя я смог заглянуть в код и понять, чего не хватает, у меня слишком мало знаний о структуре, которая здесь используется, и о том, о чем мне придется позаботиться. Извините. :не вижу зла:

Я думаю, что это довольно изолированное исправление, но да, оно требует взгляда на Tornado, так что не беспокойтесь, спасибо, что сообщили об этом.