Зачем рандомизировать имена файлов для облачного хранилища / CDN? - PullRequest
6 голосов
/ 09 октября 2011

Когда вы смотрите изображение профиля в социальной сети, такой как Twitter, они сохраняют файлы изображений, например:

http://a1.twimg.com/profile_images/1082228637/a-smile_twitter_100.jpg

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

Я использую Amazon S3, поэтому у меня будет один поддомен, обслуживающий весь мой статический контент. Мой план состоял в том, чтобы сохранить целочисленный идентификатор в моей базе данных, а затем просто объединить URL с идентификатором, чтобы сформировать местоположение.

Ответы [ 3 ]

11 голосов
/ 09 октября 2011

Одна из причин, по которым я шифрую идентификаторы в общедоступных URL-адресах, заключается в том, что темпы роста бизнеса не всегда общедоступны.

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

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

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

Вот модуль CPAN (Perl), который я поддерживаю, который шифрует 32-битные идентификаторы с использованием двустороннего шифрования на основе SkipJack:

http://metacpan.org/pod/Crypt::Skip32

Это прямой перевод алгоритма Skip32, написанный на C Грегом Роузом:

http://www.qualcomm.com.au/PublicationsDocs/skip32.c

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

Я конвертирую зашифрованный идентификатор в 8 шестнадцатеричных цифр для отображения в URL.

Как только ваши идентификаторы приблизятся к 4,29 миллиардам (32-битным), вам нужно будет планировать расширение структуры URL для поддержки большего, но мне нравится иметь более короткие URL как можно дольше.

4 голосов
/ 11 октября 2011

Изменение URL-адресов - это безопасный способ аннулировать устаревшие ресурсы.

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

2 голосов
/ 09 октября 2011

В основном, это предотвращает конфликты имен. Например, несколько человек могут загрузить IMG_0001.JPG. Вы также избегаете ограничений на количество файлов в одном каталоге и можете разделять изображения на нескольких серверах - такой огромный сайт, как Twitter или Facebook, не может хранить все фотографии на одном сервере, независимо от их размера.

...