Hey there, let's work through this WebView issue you're dealing with. It's super common for sites to behave differently in WebView vs. regular browsers—usually because the site is blocking non-standard client environments. Here are the most effective fixes to try, ordered by how likely they are to resolve your problem:

1. Spoof the User-Agent String #

Most websites check the User-Agent header to identify what kind of client is making the request. WebView uses a default UA that's often flagged as "untrusted" by sites like this one. To fix it, set your WebView's UA to match a popular desktop or mobile browser:

// Example: Mimicking Chrome on Windows
webView.getSettings().setUserAgentString("Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36");

You can tweak this to match the latest UA string for your target browser, but this example should work for most cases.

2. Enable Essential WebView Settings #

WebView disables some browser-like features by default, which can cause sites to block access. Make sure these settings are turned on:

WebSettings webSettings = webView.getSettings();
webSettings.setJavaScriptEnabled(true); // Many sites rely on JS to load content
webSettings.setDomStorageEnabled(true); // Required for modern web apps to store data
webSettings.setLoadWithOverviewMode(true); // Fits content to the screen
webSettings.setUseWideViewPort(true); // Uses the full viewport width

These tweaks make your WebView behave much more like a standard browser environment.

3. Allow Cookies and Third-Party Cookies #

Sites often use cookies to track sessions or verify authorization. WebView isolates its cookie storage from the system browser, so you need to explicitly enable cookie handling:

CookieManager cookieManager = CookieManager.getInstance();
cookieManager.setAcceptCookie(true);

// For Android 5.0+ (Lollipop), enable third-party cookies if the site uses them
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
    cookieManager.setAcceptThirdPartyCookies(webView, true);
}

This ensures any session cookies the site sets are retained, which might be required to access the restricted resource.

4. Add a Referer Header (If Needed) #

Some sites block requests that don't come from their own domain (checking the Referer header). If the site expects this, you can manually add it using a WebViewClient:

webView.setWebViewClient(new WebViewClient() {
    @Override
    public WebResourceResponse shouldInterceptRequest(WebView view, WebResourceRequest request) {
        Map<String, String> modifiedHeaders = new HashMap<>(request.getRequestHeaders());
        // Set the referer to the site's root domain
        modifiedHeaders.put("Referer", "http://noipa.mef.gov.it/");

        try {
            URL url = new URL(request.getUrl().toString());
            HttpURLConnection connection = (HttpURLConnection) url.openConnection();
            
            // Apply the modified headers
            for (Map.Entry<String, String> header : modifiedHeaders.entrySet()) {
                connection.addRequestProperty(header.getKey(), header.getValue());
            }

            return new WebResourceResponse(
                    connection.getContentType(),
                    connection.getContentEncoding(),
                    connection.getInputStream()
            );
        } catch (IOException e) {
            e.printStackTrace();
        }

        return super.shouldInterceptRequest(view, request);
    }
});

This trick helps the site recognize your request as coming from a legitimate page on its own domain.

5. Handle SSL Certificates (If the Site Redirects to HTTPS) #

While your target URL uses HTTP, some sites redirect to HTTPS behind the scenes. If you run into SSL errors, you can temporarily bypass them (only for testing—never do this in production):

webView.setWebViewClient(new WebViewClient() {
    @Override
    public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) {
        handler.proceed(); // Bypasses SSL errors; remove this in production!
    }
});

For production, you should properly handle SSL errors to avoid security risks.

Start with the User-Agent fix first—it's the most common culprit here. If that doesn't work, work your way down the list.

内容的提问来源于stack exchange，提问作者Moustafa EL-Saghier