Плохо ли обнаружение / сниффинг пользовательского агента на стороне сервера? - PullRequest
25 голосов
/ 23 января 2012

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

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

Ответы [ 3 ]

18 голосов
/ 08 апреля 2012

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

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

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

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

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

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

Обновление

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

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

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

Потенциальные улучшения

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

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

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


Для дальнейшего чтения я отсылаю вас к этой статье от Mozilla

https://developer.mozilla.org/en/Browser_detection_using_the_user_agent

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

4 голосов
/ 09 апреля 2012

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

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

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

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

  • Всегда четко определяют изменения содержания вашего сайта, когда высоздать модальное представление.Это позволит очистить все FUD , в которые внесены изменения, которые вы могли или не могли внести.

  • Всегда укажите пути к альтернативным версиям вашегосайт.Например, используйте что-то вроде http://mobile.example.org для миграции людей на мобильную версию, делая на уровне проекта предположение, что когда запрашивается этот путь, он был явно запрошен вашей аудиторией.

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

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

  • Никогда ограничить доступ к областям сайта на основе пользовательского агента (вместо этого он строго предупреждает пользователей)о том, что не сработает, если они сойдут с рельсов и разработают вашу политику поддержки вокруг этого).Например, многие из нас с любовью помнят, как меняли наших агентов для сайтов, «которые лучше всего работают в Internet Explorer», запрещая все другие браузеры.Вы не должны становиться еще одним примером этой плохой практики, если ее можно избежать.

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

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

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

2 голосов
/ 08 апреля 2012

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

В такой ситуации я бы реализовал что-то похожее на Facebook - они определяют на основе UA (и, возможно, другие вещи, такие как «анализ отпечатков пальцев»), следует ли перенаправить на мобильную версию (то есть http://m.facebook.com/...) или нет ( то есть http://www.facebook.com...). В то же время они предлагают параметр URL m2w, который переопределяет этот механизм перенаправления.

В зависимости от оператора мобильной связи может даже случиться, что у него есть некоторый контент-прокси / кэш, который масштабирует / повторно сжимает изображения на лету и выглядит на вашем конце как «обычный» браузер ...

Думая о сценариях вне браузера ... например, если вы обслуживаете какой-то определенный протокол (например, WebDAV), это может быть единственным вариантом, чтобы иметь какое-то «платформо-специфическое» поведение (например, разницу между OS X и Windows).

...