Android okhttp user agent

okhttp/4.9.0 user agent is blocked in potential bot crawling lists #1364

Comments

e-minguez commented Feb 16, 2021

Home Assistant Android version:
2021.1.1-full

Android version:
10

Phone model:
OP5T

Home Assistant version:
2021.1.4

Last working Home Assistant release (if known):

Description of problem:
The user agent used by the android app (okhttp/4.9.0) seems to be pretty generic and it is being blocked in some blacklists (see JayBizzle/Crawler-Detect#437)

I guess it would be better to modify the user-agent with something less generic to avoid being blocked.

Screenshot of problem:

Additional information:

bunkerized-nginx uses these lists, and it blocks access to home-assistant when trying to log in as:

The text was updated successfully, but these errors were encountered:

dshokouhi commented Feb 16, 2021

What’s wrong with just removing it from blocked list? It is up to every user who uses a block list to ensure it blocks what they want and to modify it for their ow needs. Not to mention there can be other things dependent on the user agent string such as the HA frontend to understand the android app is talking to it. I don’t think this is something the app should be fixing.

e-minguez commented Feb 16, 2021

What’s wrong with just removing it from blocked list? It is up to every user who uses a block list to ensure it blocks what they want and to modify it for their ow needs. Not to mention there can be other things dependent on the user agent string such as the HA frontend to understand the android app is talking to it. I don’t think this is something the app should be fixing.

There is nothing wrong with it but I guess it would be better if instead using a generic user agent, the app uses its own u-a so you can identify it properly (something like home-assistant-android — )

dshokouhi commented Feb 16, 2021

So when you say its blocked are you seeing the frontend load at all? What parts of the app work and doesn’t work? Do sensors update?

e-minguez commented Feb 17, 2021

So when you say its blocked are you seeing the frontend load at all? What parts of the app work and doesn’t work? Do sensors update?

Let me elaborate my issue.

I have my home-assistant instance running in a container. To expose it, I’m using bunkerized-nginx, which can block requests based on different methods, including ‘bad’ user-agents. In order to block those user agents, it uses public lists of known bots and crawlers, such as JayBizzle/Crawler-Detect that includes okhttp

After disabling the user-agent filtering, I can access my home-assistant instance, but I think it would be nice to customize the user-agent in the android application so it can be identified itself instead of a vague ‘okhttp’.

I’ve requested also to remove ‘okhttp’ from the list but I still think the ‘best practice’ would be to customize the user-agent.

anarion80 commented Feb 25, 2021

Oh boy! I was struggling for days to get HA on Android to connect to my Home Assistant remotely, and in the end it was this issue.
I have OPNsense with Nginx plugin set up on my router and I use that as a reverse proxy for my HA. Everything works fine when I connect remotely from Chrome or any other browser, but HA Android app is unable to authenticate (get token I think). After checking dozens of similar issues everywhere, I found this log on my router:

192.168.2.195 — — [24/Feb/2021:00:00:00 +0100] «POST /api/webhook/49ef04f73e868c444226a3fded8475bd6d440d3a160b78115d4b1606ccaf4a8e HTTP/2.0» 403 44 «-» «okhttp/4.9.0» «-«

After digging some more, turns out you can’t edit the blacklist on OPNsense, but you can disable it. So after enabling «Disable Bot Protection» under my HTTP Server entry in OPNSense/Nginx settings — everything started working as expected.

So while I understand there is a workaround, it would be great it HA app user-agent could be updated to something not present on various block lists.

sondreen commented Mar 10, 2021

I seem to be struggling with the same issue, though I can’t solve the issue as I see no mention of user-agent-filtering or bot protection on the Nginx Web UI, also can’t find any config-files I could change parameters on. I’ve posted a thread on the forums and any help would be highly appreciated, thank you.

e-minguez commented Mar 10, 2021

It seems okhttp does indeed support changing the user-agent via interceptors https://square.github.io/okhttp/interceptors/#application-interceptors

dshokouhi commented Mar 10, 2021

So I had tried to test those above changes however I do not have an environment setup to see the headers in the logs nor do they print to logcat. So I could attempt to make changes and submit a PR if you guys are willing to test the debug APK that gets generated. Would you guys be ok with that? Debug APKs are fine to install side by side the production app and can be safely removed once done testing.

anarion80 commented Mar 10, 2021

Sure, I can test.

dshokouhi commented Mar 10, 2021

@anarion80 ok the debug APK is ready for testing, you can find it here in the actions tab: https://github.com/home-assistant/android/actions/runs/640306067

Please comment on the linked PR and if possible show the output you are getting 🙂

anarion80 commented Mar 10, 2021 •

With the debug app the connection process goes through with my Bot Protection enabled and doesn’t get banned, the new user-agent is visible:

192.168.2.195 — — [10/Mar/2021:20:12:17 +0100] «POST /auth/login_flow/a755064164e341abaf4b3d17a7a4c72a HTTP/2.0» 200 189 «https://redacted/auth/authorize?response_type=code&client_id=https://home-assistant.io/android&redirect_uri=homeassistant://auth-callback» «Mozilla/5.0 (Linux; Android 11; Nokia 8.3 5G Build/RKQ1.200928.002; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/88.0.4324.181 Mobile Safari/537.36» «-» 192.168.2.195 — — [10/Mar/2021:20:12:17 +0100] «POST /auth/token HTTP/2.0» 200 337 «-» «HomeAssistant/Android LOCAL-1» «-» 192.168.2.195 — — [10/Mar/2021:20:12:29 +0100] «GET /api/discovery_info HTTP/2.0» 200 202 «-» «HomeAssistant/Android LOCAL-1» «-» 192.168.2.195 — — [10/Mar/2021:20:12:29 +0100] «POST /api/mobile_app/registrations HTTP/2.0» 201 128 «-» «HomeAssistant/Android LOCAL-1» «-» 192.168.2.195 — — [10/Mar/2021:20:12:29 +0100] «GET /?external_auth=1 HTTP/2.0» 200 1388 «-» «Mozilla/5.0 (Linux; Android 11; Nokia 8.3 5G Build/RKQ1.200928.002; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/88.0.4324.181 Mobile Safari/537.36» «-«

At the same time, with the same router setting, the original HA app gets banned and cannot find the server.

After logging in with the debug app during Registering Application, there is an error popping up:
Firebase Error: By skipping/ignoring this error you will be unable to receive any push notifications.
Not sure if this is wrong or even related.

dshokouhi commented Mar 10, 2021

The error is safe to ignore as notifications do not work in the debug build. Thank you for confirming the user agent change and that is working for your setup.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

React Native & okhttp на Android — Установить User-Agent

Я пытаюсь установить User-Agent с помощью React Native на Android. Провел небольшое исследование и, похоже, мне следует использовать okhttp Перехватчик . Пример, который я нашел, объясняет, как это должно быть сделано (Ссылка), но тогда я не уверен, как зарегистрировать перехватчик.

Итак, чтобы установить User-Agent , я использую этот класс:

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

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

ОБНОВЛЕНИЕ : Я сейчас пытаюсь зарегистрировать перехватчик в MainActivity , но он его не подхватит:

4 ответа

Итак, я наконец понял это. Вот решение для замены User-Agent okhttp с помощью React Native.

Создайте файл с именем CustomInterceptor.java :

Затем в MainActivity.java переопределить метод onCreate :

Обратите внимание, что я импортирую com.facebook.react.modules.network.OkHttpClientProvider; и переопределяю этого клиента вместо создания ванильного OkHttpClient , поскольку это тот, который будет использовать React Native.

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

Рассмотрите возможность использования addHeader(«User-Agent», «Trevor») вместо header(«User-Agent», «Trevor») , потому что последний заменит все уже установленные заголовки.

Я использую okHttp.networkInterceptors().add(new CustomInterceptor()); вместо okHttp.interceptors().add(new CustomInterceptor()); , но не думаю, что это вызывает беспокойство.

Обновление Я тоже делаю это в методе onCreate() . Все работает как надо.

Старая проблема, но мы все еще сталкивались с той же проблемой с React Native 0.59. Вот что мы сделали, чтобы исправить (в Kotlin), поскольку последние версии okhttp предотвращают (и вызывают исключение) при попытке добавить перехватчик к уже инициализированному клиенту:

Это было сделано в общей библиотеке между двумя приложениями, поэтому мы передали имя приложения, версию и номер сборки.

Использование самого приложения выглядело так:

Это было вызвано из метода onCreate в основном действии приложения.

Надеюсь это поможет!

React Native повторяется так быстро, что принятый ответ у меня не сработал.

Для RN 0.27.2 мне пришлось импортировать okhttp3.OkHttpClient в свой CustomInterceptor и изменить метод attachInterceptor () в MainActivity, чтобы заменить клиента.

Все остальное из ответа ekonstantinidis работает для меня.

Источник

Requests should send a default user-agent #982

Comments

mpost commented Jul 4, 2014

Requests made with okhttp 2.x do not set a proper user-agent. I would expect to see a default user agent. Maybe similar to the one used by picasso:

Dalvik/1.6.0 (Linux; U; Android 4.4.4; Nexus 5 Build/KTU84P)

The text was updated successfully, but these errors were encountered:

StErMi commented Sep 16, 2014

My device (nexus 5) is recognized as a Tablet

UserAgent from Chrome for Android:

UserAgent inside the app that is using OkHTTP:

is there a workarond until we get an official fix?

StErMi commented Oct 4, 2014

Hi guys, is there a way, with OkHTTP 2.0 to set custom User-Agent?

I get this exception:

mpost commented Oct 4, 2014

Set the user agent before calling .open().

JakeWharton commented Oct 4, 2014

open() creates the HttpURLConnection instance (but doesn’t connect). I suspect you omitted some of the code, one line of which is causing the connection to trigger.

Magudesh commented May 13, 2019

Requests made with okhttp 2.x do not set a proper user-agent. I would expect to see a default user agent. Maybe similar to the one used by picasso:

Dalvik/1.6.0 (Linux; U; Android 4.4.4; Nexus 5 Build/KTU84P)

I want to know why that dalvik user agent is coming ?

Источник

twaddington / UserAgentInterceptor.java

This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters

package com.enlighthq.mobile.http ;

import android.os.Build ;

import java.io.IOException ;

import java.util.Locale ;

import okhttp3.Interceptor ;

import okhttp3.Request ;

import okhttp3.Response ;

/**

* Adds a custom < @code User-Agent >header to OkHttp requests.

*/

public class UserAgentInterceptor implements Interceptor <

public final String userAgent;

public UserAgentInterceptor ( String userAgent ) <

this . userAgent = userAgent;

>

public UserAgentInterceptor ( String appName , String appVersion ) <

this ( String . format( Locale . US ,

» %s/%s (Android %s; %s; %s %s; %s) » ,

appName,

appVersion,

Build . VERSION . RELEASE ,

Build . MODEL ,

Build . BRAND ,

Build . DEVICE ,

Locale . getDefault() . getLanguage()));

>

@Override

public Response intercept ( Chain chain ) throws IOException <

Request userAgentRequest = chain . request()

.newBuilder()

.header( » User-Agent » , userAgent)

.build();

return chain . proceed(userAgentRequest);

>

>

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Какую библиотеку работы с HTTP в Android выбрать?

Представляю вашему вниманию перевод статьи «Which Android HTTP library to use?».

Для чего это вообще?

Немного истории

До Froyo HttpURLConnection имел некоторые не очень приятные баги. В частности, вызов close() у читаемого InputStream мог испортить пул соединений.

… большой размер их API мешает нам улучшать эту библиотеку без потери обратной совместимости. Команда Android не работает активно над Apache HTTP Client.

Apache HTTP client имеет мало багов на Eclair и Froyo, поэтому он является лучшим выбором для этих версий. А для Gingerbread и младше лучше подходит HttpURLConnection. Простота API и небольшой вес хорошо подходят для Android. Прозрачное сжатие и кэширование ответов помогают увеличить скорость и сохранить батарею. Новые приложения должны использовать HttpURLConnection.

Даже сегодня, если вы загляните в исходники Volley от Google (о ней я расскажу чуть попозже), вы сможете найти такое наследие:

Это классический пример фрагментации Android, которая заставляет страдать разработчиков. В 2013 году Square обратила внимание на эту проблему, когда выпускала OkHttp. OkHttp была создана для прямой работы с верхним уровнем сокетов Java, при этом не используя какие-либо дополнительные зависимости. Она поставляется в виде JAR-файла, так что разработчики могут использовать ее на любых устройствах с JVM (куда мы включаем, конечно, и Android). Для упрощения перехода на их библиотеку, Square имплементировали OkHttp используя интерфейсы HttpUrlConnection и Apache client.

OkHttp получила большое распространение и поддержку сообществом, и, в конце-концов, Google решили использовать версию 1.5 в Android 4.4 (KitKat). В июле 2015 Google официально признала AndroidHttpClient, основанный на Apache, устаревшим, вместе с выходом Android 5.1 (Lolipop).

Сегодня OkHttp поставляется со следующим огромным набором функций:

1. Поддержка HTTP/2 и SPDY позволяет всем запросам, идущим к одному хосту, делиться сокетом
2. Объединение запросов уменьшает время ожидания (если SPDY не доступен)
3. Прозрачный GZIP позволяет уменьшить вес загружаемой информации
4. Кэширование ответов позволяет избежать работу с сетью при повторных запросах.
5. Поддержка как и синхронизированных блокирующих вызовов, так и асинхронных вызовов с обратным вызовом (callback)

Моя самая любимая часть OkHttp – как красиво и аккуратно можно работать с асинхронными запросами:

Это очень удобно, так как работа с сетью не должна быть в UI потоке. По-факту, начиная с Android 3.0 (Honeycomb, API 11), работа с сетью в отдельном потоке стала обязательной. Для того, чтобы воплотить что-то похожее с HtttpUrlConnection, вам потребуется построить большую (а может и монструозную) конструкцию с использованием AsyncTask или отдельного потока. Это будет еще более сложным, если вы захотите добавить отмену загрузки, объединение соединений и т.п.

Кстати, не осталась у обочины и HTTP библиотека от Google под названием Volley, которая предоставляет нам следующие бонусы:

1. Автоматическое планирование сетевых запросов
2. Множество параллельных сетевых соединений
3. Прозрачное кэширование в памяти и на диске, в соответствии со стандартной кэш-согласованностью.
4. Поддержка приоритизации запросов.
5. Отмена API запросов. Вы можете отменить как один запрос, так и целый блок.
6. Простота настройки, например, для повторов и отсрочек.
7. Строгая очередность, которая делает легким корректное заполнение данными, полученными асинхронно из сети, интерфейса пользователя.
8. Инструменты отладки и трассировки

Все, что ни есть в Volley, находится на вершине HttpUrlConnection. Если вы хотите получить JSON или изображение, то Volley имеет на это специальный абстракции, такие как ImageRequest и JsonObjectRequest, которые помогают вам в автоматическом режиме конвертировать полезную нагрузку HTTP. Так же достойно внимания то, что Volley использует жестко запрограммированный размер сетевого пула:

Когда OkHttp использует поток для каждого вызова с ThreadPoolExecutor с максимальным значением Integer.MAX_VALUE:

В результате, в большинстве случаев OkHttp будет действовать быстрее за счет использования бОльшего количества потоков. Если по каким-то причинам вы захотите использовать OkHttp вместе Volley, то есть реализация HttpStack, которая использует API запросов/ответов из OkHttp заместо HttpURLConnection.

HTTP клиенты продолжили развиваться для поддержки приложений с большим количеством картинок, особенно тех, кто поддерживает бесконечную прокрутку и трансформацию изображений. В то же время, REST API стал стандартом в индустрии, и каждый разработчик имел дело с такими типовыми задачами как сериализация в/из JSON и преобразование REST-вызовов в интерфейсы Java. Не прошло много времени, как появились библиотеки, решающие эти задачи:

1. Retrofit – типобезопасный HTTP Android клиент для взаимодействия с REST-интерфейсами
2. Picasso – мощная библиотека для загрузки и кэширования изображений под Android

Retrofit предоставляет некий мост между Java кодом и REST-интерфейсом. Он позволяет быстро включить в ваш проект HTTP API интерфейсы, и генерирует самодокументирующуюся реализацию.

В дополнение ко всему, Retrofit поддерживает конвертацию в JSON, XML, протокол буферов (protocol buffers).

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

Picasso и Retrofi настроены так, чтобы использовать OkHttpClient как стандартный HTTP клиент. Однако, если хотите, вы можете указать клиентом HttpURLConnection.

Glide – что-то похожее на Picasso. Он предоставляет некоторые дополнительные функции, такие как GIF-анимация, генерация миниатюрных эскизов изображения и неподвижные видео. Полное сравнение можно найти здесь.

Facebook недавно открыли общественности исходный код библиотеки Fresco, которую они используют в своем мобильном приложении. Одна из ключевых функций, которая выделяет ее, — кастомная стратегия выделения памяти для bitmap’ов, чтобы избежать работы долгого GC (сборщик мусора). Fresco выделяет память в регионе, который называется ashmem. Используются некие трюки, чтобы иметь доступ к этому региону памяти доступ как из части, написанной на C++, так и из части на Java. Чтобы уменьшить потребление CPU и данных из сети, эта библиотека использует 3 уровня кэша: 2 в ОЗУ, третий во внутреннем хранилище.

Я нашел необходимым показать отношения между библиотеками на одной схеме. Как вы можете увидеть, HTTP всегда остается внизу у высокоуровневых библиотек. Вы можете выбирать между простым HttpUrlConnection или последним OkHttpClient. Мы используем эту совместимость при разработке PacketZoom Android SDK, о котором мы поговорим в следующем посте.

Недавно мы сравнивали между собой HTTP библиотеки по производительности, но эта тема заслужила отдельного рассмотрения. Мы надеемся, что этот обзор дал вам основные идеи о плюсах и минусах каждой библиотеки, и мы помогли вам сделать правильный выбор. Следите за выходом более интересных постов о сетевой работе в Android от нас.

Источник