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

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

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

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

Solutions Collecting From Web of "Как Google может обнаружить запрос из WebView?"

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

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

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

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

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

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

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

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

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

X-Requested-With: the.app.packageName

Вы можете различать строку пользовательского агента. См. 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 есть дополнительная строка версии.