Как Google может обнаружить запрос из WebView?

Google объявила, что "больше не будет разрешать запросы OAuth для Google во встроенных браузерах, известных как" веб-представления".

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

Есть ли способ обнаружить серверную сторону - и независимо от того, что делает клиент, - запрос из Android WebView. Как это делается Google?

Ответ 1

Не отвечая на ваш вопрос напрямую (извините), но в отношении устаревания WebView для OAuth, на который вы ссылались: даже если вы обнаружите способ избежать обнаружения WebView во время потока OAuth, это может привести к нарушению Google API Services: Политика пользовательских данных, в частности раздел "Не вводите Google в заблуждение о рабочей среде приложения". Поэтому я бы не рекомендовал этого.

Обычно использование пользовательских вкладок для OAuth (например, через AppAuth для Android) приводит к лучшему опыту пользователя в любом случае, так как пользователь, скорее всего, уже будет входить в систему Google позволяет им просматривать ваш запрос без повторной регистрации. Это также более безопасный эксперимент. То, что цель миграции - более безопасный, более удобный для OAuth эксперимент для конечных пользователей: -)

Ответ 2

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

однако есть libaray https://github.com/Valve/fingerprintjs2, чтобы вы могли прочитать это, чтобы увидеть подробности того, что они делают. поскольку он создает отпечаток устройства, поэтому Google может использовать галочки, подобные этому, для обнаружения /

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

Также возможно, как описанный выше метод, что они могут использовать систему chrome://в скрытом iframe и обнаруживать содержимое из него для идентификации EG chrome://about-view/и печатать жестко закодированный User-Agent, снова единственный способ обойти это, это бросить ваш собственный браузер.

Как сказал @WilliamDenniss, делая кругосветку заголовка, если они обнаруживают, что могут заблокировать ваше приложение и вашу учетную запись, а также все приложения на вашем аккаунте и не позволяют вам снова публиковать приложение из этой учетной записи.

Ответ 3

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

Ответ 4

Все HTTP-запросы, отправленные через webview, имеют заголовок X-Requested-With, который может быть использован для обнаружения запроса от веб-просмотра.

X-Requested-With: the.app.packageName

Ответ 5

Вы можете различать через строку пользовательского агента. См. https://mobiforge.com/research-analysis/webviews-and-user-agent-strings

например. браузер Chrome Chrome по умолчанию содержит следующие "(KHTML, например, Gecko) Chrome/xx.xx...", но веб-просмотры по умолчанию имеют следующий шаблон "(KHTML, например Gecko) Версия /4.0 Chrome/xx.xx.." Кажется, webview имеет дополнительную строку версии.