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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BTW, циклическое соответствие избыточности на самом деле является методом исправления ошибок и не столько методом шифрования.

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

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

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

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