-
Notifications
You must be signed in to change notification settings - Fork 711
WebView sends X-requested-with header #1196
Comments
Could be replaced with an empty string |
SO agrees: https://stackoverflow.com/a/29395509/2219998 For this bug, please first investigate if it's possible to remove the header entirely (e.g. can we pass in null?), then fallback on sending an empty String. |
I've been looking into this for most of today, so I'm going to write down some of my findings for anyone who might look at this later. I've personally come to the conclusion that you can't use Android's WebView system as is and remove the X-Requested-With header from all outbound HTTP headers. At least this is what my research leads me to believe, and also because I've tried a few such implementations that should achieve this but they don't actually squelch that header. You can get rid of it at SystemWebView.loadUrl() (quite easily I might add), but it doesn't matter because if the page loads any other assets like a stylesheet you still have the X-Requested-With header present in that request (and every other request except the initial one). Trying to manually add the header to the WebSourceRequest in TrackingProtectionWebViewClient.shouldInterceptRequest() doesn't stop the header from being present with the package name. My research into some other Android browsers that would also likely want to remove this header currently don't successfully do it either. Some have had this same issue open for ~18 months. Stopping "android.webkit.WebStorage" from getting the correct package name causes a complete app crash, though I haven't been able to discern if stopping "android.webkit.WebViewFactory" from getting the correct package name actually impacts anything. But even if it does/doesn't it still doesn't stop the X-Requested-With header from showing up. So that might remove the option of just not telling the webkit what the package name is so it can't use it. I think there might be a way to do it with HttpURLConnection but I'm not sure about that. In theory it means you'd need to be able to respond to every single type of content you might receive if I'm understanding it correctly. Would that even be a viable solution if it were the case? |
Thank you @JordanShaak for your thorough research. That's great!
Back when I filed this issue I tried a bunch of things too and couldn't find a way. Did you look into the Chromium issue tracker whether there's an issue filed for that? If not then we should file it.
We have the same issue with the DNT header (#446). We can add it to the first request but not to all of them. However I think it would be worth removing X-Requested-With from the initial request - even though we cannot remove it from all yet. Again I wonder if this is tracked in the Chromium bug tracker. If not we should file an issue for this one too.
That's interesting. Haven't tried this one. Too bad it doesn't work.
Does this mean intercepting all requests and performing them manually with HttpURLConnection? So far I do not want to go this route. The risk of introducing a lot of bugs is just too high. Doing all this manually is definitely not trivial and I expect a bunch of edge cases. |
I took a look recently and didn't find anything, but it's very possible I missed it/am not using the correct search terms in the issue tracker. Since this isn't the first time a project has had this issue I feel as though someone must have submitted the issue before, but I can't find any proof of it.
If I can manage to get my local version cleaned up and not mangle the pull request for that I'll submit one later.
Pretty much exactly what I was trying to say, and...
... the same conclusion my research was leading me to. |
Merged the patch that clears the "X-Requested-With" header for the initial request. That's everything we can do here. |
Re-opening again: We could check the chrome issue tracker and file issues if needed. |
the value of X-requested-with is from getAll() method in org.chromium.base.BuildInfo getAll()[8] is the key
so if we can change the value , X-requested-with is resolved |
// xxApplication.java
@Override
public String getPackageName() {
try {
StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace();
for (StackTraceElement element : stackTrace) {
if ("org.chromium.base.BuildInfo".equalsIgnoreCase(element.getClassName())) {
if ("getAll".equalsIgnoreCase(element.getMethodName())) {
String customPackageName = "com.tencent.qq";
return customPackageName;
}
break;
}
}
} catch (Exception e) { }
return super.getPackageName();
} |
Overriding the header is possible and we already do that:
However getting completely rid of it is not possible. |
still failing on some pages allowing only chrome. i don't get what they are tracking anything except X-Requested-With. There must be some .js checks. |
I am going to close this issue: All variants of Focus that we ship are using GeckoView now and therefore do not send this header anymore. |
this worked for me |
WebView seems to send an HTTP header with the application id:
For Klar:
Or Dev/Beta builds:
I wonder if this is problematic. We already use "Focus"/"Klar" in the user agent. But this additionally shows the build type.
The text was updated successfully, but these errors were encountered: