WebView APKs leveraging setUserAgentString does not apply to requests passing through ServiceWorkers
Reported by
ccr...@twitter.com,
Nov 30 2017
|
|||||
Issue description
Steps to reproduce the problem:
1. Create an APK which uses WebViews.
final WebSettings settings = mWebView.getSettings();
final String defaultUA = settings.getUserAgentString();
settings.setUserAgentString(defaultUA + " CustomAgent");
2. Go to a site which uses a service worker to proxy SOME requests
self.addEventListener('fetch', (event) => {
if (event.request.method == 'POST') {
event.respondWith(
fetch(event.request)
)
}
});
3. Inspect the request using a proxy or on the server. Notice that GET requests have the proper user agent (CustomAgent) while POST requests are missing the web view modifications.
What is the expected behavior?
All network requests should have the altered user agent when initiated from within a controlled web view.
What went wrong?
I'm guessing ServiceWorkers somehow operate independent of the WebView in Chrome. Therefore, whatever they proxy somehow regenerates certain headers and either does not preserve those of the original request, or does not respect the WebView user agent.
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 62.0.3202.62 Channel: stable
OS Version: 8.0
Flash Version:
,
Dec 1 2017
Actually probably not. issue 595993 is about the User Agent header visible inside the FetchEvent's request. I'd expect fetch() from a service worker to go through the same path as fetch() from a page. Does the same error occur when a page calls fetch()?
,
Dec 1 2017
Ah sorry yeah. The SW is reissuing fetch.request so it is likely related. Also it looks like we plumb a user_agent field to WorkerGlobalScope which WorkerFetchContext uses. Where does WebView inject the UserAgent? Chrome seems to do it via ChromeContentClient::GetUserAgent. Not really sure how all these layers interact.
,
Dec 1 2017
,
Dec 1 2017
Sorry. The dup bug is restricted. I'm trying to remove that restriction, and if I can't I'll undup.
,
Dec 1 2017
Ok, I can't remove the restriction. Unduped.
,
Dec 1 2017
The useragent override is specific to a particular WebView instance. This means that service worker requests are not going to have their useragents overridden because service worker requests don't have a WebContents, and in fact it's possible for the same service worker to be being used simultaneously by two different WebView instances with different useragents. So, I think this is unfixable other than by adding a new API to set the useragent to use for service worker requests, to the recently-added ServiceWorkerController.
,
May 7 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by falken@chromium.org
, Nov 30 2017