Хранение пользовательских данных

Ответ 1

Проще говоря, я думаю, что это может сводиться к двум основным причинам: Безопасность и кэш:

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

Подумайте, что произойдет, если я могу легко угадать URL вашего профиля и загрузить его, даже если вы явно решили поделиться им только с друзьями.

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

Если вы хотите сохранить один и тот же URL-адрес для каждой фотографии профиля пользователя (например, https://scontent-lhr3-1.xx.fbcdn.net/{{ profile_id }}/50x50.png), а затем загрузить новую фотографию, может произойти одно из следующих:

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

Надеюсь, это прояснит это.

Ответ 2

Компании, подобные Facebook, имеют достаточно интенсивные CDN. Они могут выглядеть как произвольно сгенерированные URL-адреса, но это не так, каждый индивидуальный маршрут предназначен специально и запрограммирован для обработки таким образом.

Они не после простоты хранения, как если бы вы использовали FTP для подключения к базовому серверу веб-маркетинга. Хотя вы можете поместить все свои изображения в папку /images, Facebook слишком сложен для этого. Десятки различных типов приложений получают доступ к сотням, если не тысячам CDN и серверам по всему миру.

Если вы когда-либо создавали веб-приложение, такое как приложение Ruby on Rails, и вы работаете с такими сервисами, как AWS (Amazon Web Services), вы также столкнетесь с тем, что кажется бессмысленным. Но все это часть сети быстрой доставки, предоставляемой в рамках архитектуры. Каждый раз, когда вы "нажимаете" свое приложение на сервер, для каждого уникального ресурса автоматически генерируются новые URL-адреса, файлы css, файлы JavaScript, файлы изображений и т.д. Все динамически создаются. Вам не нужно вводить каждый из этих уникальных URL-адресов каждый раз, когда вы публикуете приложение, код просто знает, где искать их как часть процесса публикации.

Пример: вы скажете веб-приложению искать

//= require jquery

и он вернет вам http://example.com/assets/jquery-eb3e278249152b5b5d5170b73d9dbf52.js?body=1 в ваш заголовок.

Не имеет значения, что URL-адрес более сложный, чем он должен быть, приложение распознает его и что все, что имеет значение.

Ответ 3

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

Ответ 4

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

Я использую, чтобы работать в компании, где мы используем для сопоставления публикации в Facebook, используя Graph API, чтобы получить свой объект Insights и извлечь из него информацию для удобного прохождения в пользовательском интерфейсе и отправки обратно в наш магазин Redis; и как только мы определили структуру данных в TaffyDB, как будет выглядеть объектная организация, все имеет смысл с ее возможностью запрашивать полезный конечный из длинного мусорного потока потокового потока с уменьшенным Javascript См. http://www.taffydb.com/

Ответ 5

Дополнительные значения в URL-адресе полезны для:

• Отслеживать доступ. Это похоже на то, что газета добавляет "& homepage" к "& email" в URL-адрес статьи, поэтому их система знает, как читатель нашел страницу.

• Избегайте злоупотреблений и контролируйте доступ. Представьте себе, что пользователь загрузит маленькое, популярное порнографическое изображение в изображение профиля. Они могли бы захватить CDN быть свободным веб-хостинга для их порносайт. Но этот код используется внутри CDN для ограничения количества просмотров.