Google Cloud CDN не может получить доступ к файлу с пустым пространством из серверной службы GCS

Я использовал Google Cloud CDN для кэширования контента из корзины GCS в течение нескольких месяцев. До вчерашнего дня (2019/09/19) я заметил, что не могу получить доступ к объекту с пробелами в его имени. Обычно я применяю encodeURIComponent к имени объекта перед подписанием всего URL-адреса, который до вчерашнего дня работал нормально.

Вот что я пробовал использовать с gcloud утилитой:

  1. Подпишите URL без URL-кодирования имени файла:

    $ gcloud compute sign-url --key-name my-key --key-file my-key --expires-in 15m "https://cdn.example.com/file-with-white space.txt"

    Затем я обратился к URL-адресу с %20 и без него. Результат - 403, как показано на рисунке.

  2. Подпишите URL-адрес именем файла в кодировке URL (это то, что я делал в течение нескольких месяцев, и он работал нормально):

    $ gcloud compute sign-url --key-name my-key --key-file my-key --expires-in 15m "https://cdn.example.com/file-with-white%20space.txt"

    Результат тоже 403, но с другим сообщением:

Анонимный вызывающий абонент не имеет доступа к хранилищу .objects.get к имени сегмента / файла.

Я также пробовал использовать код Go из этой ссылки. Результаты такие же.

Обратите внимание, что файлы без пробелов в имени по-прежнему могут быть успешно доступны через CDN.

Обновлять

  1. Чтобы уточнить, я думаю, что поведение CDN изменилось.
  2. Я предоставил CDN доступ к корзине GCS. Поэтому раньше CDN работал без проблем. Я только что дважды gsutil iam ch serviceAccount:[email protected]:objectViewer gs://[BUCKET] запустил, чтобы убедиться в этом.
  3. Я пробовал подписывать URL-адреса GCS, используя gsutil напрямую, без использования CDN, и подписанный URL-адрес работал.

Обновление 2

Я пробовал вариант --validate. Вот что у меня получилось:

$ gcloud compute sign-url --key-name cdn-signing-key \
  --key-file cdn-signing-key --expires-in 15m \
  --validate "https://cdn.domain.com/file%20with%20space"

signedUrl: https://cdn.domain.com/file%20with%20space?Expires=1569075302&KeyName=cdn-signing-key&Signature=e3SANudKHIT5txHWVlO1oijItXw=
validationResponseCode: 200

И все же я все равно получал 403 при доступе к "signedUrl" через браузер. Результатом является страница XML с <Code>AccessDenied</Code>.


node.js google-cloud-storage google-cloud-cdn
person Kohpai Bamboo    schedule 20.09.2019    source источник
comment
›Который до вчерашнего дня работал нормально. Для ясности, вы говорите, что это поведение изменилось?   -  person elithrar    schedule 20.09.2019
comment
Кроме того, облачной CDN явно предоставлен доступ к бэкэнд-корзине для облака. google.com/cdn/docs/ -?   -  person elithrar    schedule 20.09.2019
comment
@elithrar Да, я думаю, что поведение CDN при интерпретации URL-адреса изменилось. И я уже следил за инструкцией по ссылке. Вот почему я мог использовать CDN раньше. Я также обновил вопрос, чтобы другие люди могли лучше понять контекст.   -  person Kohpai Bamboo    schedule 20.09.2019

Ответы (2)


arrow_upward
0
arrow_downward

Я не могу повторить это.

Имя файла (в кодировке URL) с пробелами в сегменте GCS может быть подписано и проверено:

➜  gcloud compute sign-url --key-name "backend-key" \
  --key-file backend.key --expires-in 7d \
  --validate "https://cloud-cdn.questionable.services/file%20with%20spaces.txt"

signedUrl: https://cloud-cdn.questionable.services/file%20with%20spaces.txt?Expires=1569639576&KeyName=backend-key&Signature=pTsgDpBOpBcqHDNeTWFfFcTC2Ws=
validationResponseCode: 200

Без кодирования URL-адресов проверка и подписание завершаются неудачно (как и ожидалось), поскольку gcloud не кодирует URL-адреса автоматически в процентах:

➜  gcloud compute sign-url --key-name "backend-key" \
  --key-file backend.key --expires-in 7d \
  --validate "https://cloud-cdn.questionable.services/file with spaces.txt"

signedUrl: https://cloud-cdn.questionable.services/file with spaces.txt?Expires=1569639586&KeyName=backend-key&Signature=AiJEBO6sHGgJh8EshLAH2IXlxe0=
validationResponseCode: 400

Не было никаких изменений ни в алгоритме подписи на стороне Cloud CDN, ни в команде sign-url в gcloud SDK. Раньше мы не использовали неявное кодирование URL для входящего URL.

person elithrar    schedule 21.09.2019
comment
Я только что опробовал вариант --validate. Вот что я получил в ответ: $ gcloud compute sign-url --key-name cdn-signing-key \ --key-file cdn-signing-key --expires-in 15m \ --validate "https://cdn.domain.com/file%20with%20space" signedUrl: https://cdn.domain.com/file%20with%20space?Expires=1569075302&KeyName=cdn-signing-key&Signature=e3SANudKHIT5txHWVlO1oijItXw= validationResponseCode: 200 Но при доступе к подписанному URL-адресу через браузер я все равно получил страницу XML с <Code>AccessDenied</Code>. Любая идея? - person Kohpai Bamboo; 21.09.2019
comment
Не имея возможности проверить URL-адрес, я не могу подтвердить ваш точный сценарий. Взгляните на журналы доступа в Stackdriver Logging и посмотрите, какая ошибка всплывает, что препятствует доступу. Я предполагаю, что у вас нет ничего подобного VPC Service Controls или аналогичного настроенного ... - person elithrar; 22.09.2019
comment
Я проверил журналы и увидел, что когда CDN пытается получить файл из корзины, корзина возвращает 301. Затем CDN перенаправляет меня на URL-адрес корзины, который, в свою очередь, возвращает 403. - person Kohpai Bamboo; 23.09.2019

arrow_upward
0
arrow_downward

Сегодня утром я снова попытался получить доступ к недавно подписанному URL-адресу файла с пробелами. Я заметил кое-что интересное.

  • Иногда CDN работает и возвращает 200 вместе с содержимым файла.
  • В других случаях CDN получает 301 в качестве ответа от серверной службы (в данном случае ведра GCS), а затем перенаправляет меня на URL-адрес корзины, который, в свою очередь, возвращает 403 вместе со страницей XML.
  • Поэтому я попытался изменить разрешение ведра на Public. Если CDN заработает, я получу 200, как и раньше. Если CDN перенаправит меня в корзину, теперь я получу 200 вместе с файлом.

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

person Kohpai Bamboo    schedule 23.09.2019