Google Storage или Amazon S3 или Google App Engine BlobStore

Ответ 1

Самый простой вариант - использовать blobstore. Вы можете предоставить любой загрузочный интерфейс, который вам нужен, - это вам, чтобы написать его, - и blobstore не ограничивает ваши URL загрузки, а только ваши загружаемые. Вы можете подавать изображения blobstore по любому URL-адресу, просто установив соответствующие заголовки, или вы можете использовать get_serving_url, чтобы воспользоваться встроенной поддержкой быстрого обслуживания изображений, которая генерирует загадочные, но согласованные URL-адреса (но не позволяет делать референт чеки).

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

Ответ 2

Всякий раз, когда я возвращаюсь к кодированию статистических веб-сервисов, мне приходилось динамически генерировать изображения и диаграммы. Сгенерированные изображения будут зависеть от параметра запроса, состояния репозитория данных и некоторой информации заголовка.

Поэтому, если бы я был вами, я бы написал веб-службу REST для обслуживания изображений. Не слишком сложно. Это довольно щекотливо, потому что, если вам не нравится какой-то конкретный IP-адрес, вы можете показать мультфильм из-за-щеки (или анимированный gif танца OBL samba при бомбежках), а не изображение для запроса данных.

В вашем случае вы можете проверить реферера (или referrer) в заголовке http, правильно? Я сомневаюсь, потому что люди могут и будут скрывать, путать или даже подделывать поле referer в http-заголовке.

Итак, не только проверьте поле референта, но и создайте поле данных, в котором изменяется значение. Значение может быть простым сопоставлением значений.

Во время мировой войны Рузвельт и Черчилль передавали шифрование. У каждого из них был одинаковый стек дисков, который каким-то образом содержал механизм шифрования. После каждого разговора оба диска будут отбрасывать диск (и никогда не будут повторно использоваться), чтобы в следующий раз, когда они снова заговорили, они достигли следующего диска в стеке.

Вместо стека дисков ваши пользователи изображений и поставщик изображений будут иметь один и тот же стек из 32-битных токенов. 32 бита дадут вам ~ 4 миллиарда десятиминутных периодов. Стек случайным образом упорядочивается. Поскольку хорошо известно, что "случайные генераторы" не являются действительно случайными и на самом деле алгоритмическими, которые можно предсказать, если они снабжены достаточно длинной последовательностью, вы должны либо использовать "истинный случайный генератор", либо повторить стеки каждую неделю.

Из-за проблем с задержкой ваш провайдер будет принимать токены из текущего периода, последнего периода и следующего периода. Где период = сектор.

Ваш клиент ajax (предположительно gwt) в вашем браузере будет получать обновленный токен с сервера каждые десять минут. Клиент ajax будет использовать этот токен для запроса изображений. Служба поставщика изображений отклонит устаревший токен, и ваш клиент ajax должен будет запросить новый токен с сервера.

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

То, как я генерирую "действительно случайные" последовательности, снова быстро и грязно. Далее я работаю над алгоритмически сгенерированной "случайной" последовательностью, проводя несколько минут вручную, бросая несколько гаечных ключей обезьян, вручную переустанавливая или удаляя значения последовательностей. Это испортило бы любую алгоритмическую предсказуемость. Возможно, вы могли бы написать маркера для обезьян. Но алгоритмический маркер-маркер обезьян просто добавит предсказуемый алгоритм выше другого предсказуемого алгоритма, который вообще не снизит общую предсказуемость.

Вы могли бы одержимо сузить ситуацию, используя циклическое дублирование, как быстрый и грязный "зашифрованный" механизм согласования токенов.

Скажем, у вас есть круг, разделенный на 8 равноудаленных секторов. У вас будет трехзначный двоичный номер, который сможет адресовать любой из 8 секторов. Представьте, что каждый сектор далее подразделяется на 8 подсекторов, так что теперь вы сможете адресовать каждый подсектор с дополнительными 3 байтами, что составит в общей сложности шесть байтов.

Вы планируете менять значение соответствия каждые 10 минут. У вашего поставщика изображений и всех ваших одобренных потребителей будет одинаковый стек адресов сектора. Каждые десять минут они выбрасывают адрес сектора и используют следующий. Когда потребитель отправляет вашему провайдеру соответствующее значение, он не отправляет адрес сектора, а адрес подсектора. Таким образом, до тех пор, пока ваш провайдер получит адрес подсектора, принадлежащий текущему принятому сектору, служба поставщика ответит правильным изображением.

Но адрес подсектора переназначается через алгоритм последовательности обфускации. так что каждый адрес подсектора внутри одного и того же сектора вообще не выглядит похожим. Таким образом, не все браузеры получат одинаковое значение токена или очень близкое значение токена.

Предположим, что у вас есть 16-битные адреса сектора, и каждый сектор имеет 16-разрядные адреса подсектора, составляющие 32-разрядный токен. Это означает, что вы можете позволить себе иметь 65536 одновременных клиентов-браузеров, имеющих один и тот же токен-сектор, но где нет двух токенов с тем же значением низкой предсказуемости. Чтобы вы могли назначить значение токена токена для каждого идентификатора сеанса. Если у вас не будет более 65536 одновременных сеансов с вашей службой поставщика изображений, ни один идентификатор сеанса не должен будет использовать один и тот же адрес токена подсектора. Таким образом, если у спамера не было доступа к оборудованию/средствам для идентификации сеансов, не было бы способа, которым ваш провайдер изображений мог бы быть спамом, за исключением атаки отказа в обслуживании.

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

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

BTW, Cyclic Redundancy matching на самом деле является методом коррекции ошибок и не столько методом шифрования.

Ответ 3

Упрощенная версия geek essay, создайте обработчик в движке Google для извлечения и обработки изображений. Вы можете изменить заголовки, чтобы указать png или что-то еще, но вы возвращаете изображение из другого места. Затем вы можете просмотреть информацию о реферере вашего запроса в обработчике и предпринять соответствующие действия, если кто-то пытается получить доступ к этому изображению "hotlinked". Конечно, потому что вы никогда не подвергаете действительный образ, было бы невозможно связаться с хотлинком. =)

Ответ 4

Вы должны знать, что File API все еще экспериментальный, проверьте эту проблему:

http://code.google.com/p/googleappengine/issues/detail?id=6888#c20

Я работаю над запуском, который выходит из Blobstore в Amazon S3