Защита веб-страницы и необходимых ресурсов с помощью Google Cloud Storage и подписанных URL-адресов?

Я пытаюсь обеспечить доступ к премиальному контенту в своем веб-приложении для приложений. Содержимое представляет собой модуль Articulate, это player.html с десятками связанных ресурсов javascript, аудио и видео. Я пытаюсь использовать Google Cloud Storage для размещения содержимого.

Моя идея заключается в том, что когда пользователь, прошедший проверку подлинности с моим приложением и имеющий соответствующие запросы на доступ к премиальному контенту, мое приложение может подписать URL-адрес player.html. Что я не уверен в том, как обрабатывать все связанные файлы ресурсов? Подписанные URL-адреса достаточно просты для защиты отдельных файлов, но как насчет групп файлов? Должен ли я подписывать URL-адреса для всего содержимого или возможно, чтобы один подписанный url разрешил доступ к связанным файлам?

Списки ACL не являются опцией, потому что я перевернул свою собственную проверку подлинности, а не использовал учетные записи oAuth и Google.

Любые мысли или альтернативные стратегии будут оценены.

Обновление 8.7.13

После размышления и изучения еще немного, я задаюсь вопросом о настройке ведра GCS в качестве веб-сайта в соответствии с инструкциями здесь.

Если я правильно понимаю документы, я бы создал CNAME, чтобы указать запросы из моего пользовательского домена content.example.com на c.storage.googleapis.com, и запрос, который прибывает через этот CNAME, подается, как если бы они были статичной веб-страницей, Кто-нибудь знает, какие средства контроля доступа доступны (если есть) в файлах, которые будут использоваться таким образом? Должны ли файлы, обслуживаемые таким образом, также требовать подписи /ACL, если они не являются общедоступными?

1 ответ

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

затемнение

Сделать все связанные ресурсы доступными и доступными в подкаталоге unguessable. Пользователь будет использовать подписанный URL для загрузки защищенного корневого ресурса, который будет включать ссылки на общедоступные вторичные ресурсы. Недостаток: субресурсы не защищены и могут быть загружены любой стороной, которая знает URL. Возможное смягчение: периодически вращать каталог под-ресурсов.

Перенаправления приложений

Изменение включает в себя маршрутизацию всех ресурсов через приложение appengine, которое будет проходить проверку подлинности с использованием собственной схемы и перенаправлять на новый подписанный URL для каждого субресурса. Нижняя сторона: много дополнительных перелетов через appengine. Например, player.html будет включать в себя фильм " https://yourapp.appspot.com/resources/movie.mov ", который попадет в приложение appengine, которое, в свою очередь, будет аутентифицироваться, а затем перенаправить на подписанный " https://storage.googleapis.com/yourbucket/movie.mov?signaturestuff "

licensed under cc by-sa 3.0 with attribution.