This seems reasonable, but it will require an Android API change, which means that it will only be possible to get this extra information on future Android releases. You'll still have this problem on existing OS versions, unfortunately :/

Maybe we can think of a way to work around the lack of this information though?

Yeah, the old Android versions are a problem. But we need to fix it at least in the newer versions. Sooner the better.

I tried to alternate ways of fixing this problem, but I have run out of ideas. Any ideas are surely welcome.

Also, I have created an Android bug to track the API changes required - 

https://code.google.com/p/android/issues/detail?id=211113

no need for android bug. we don't use them in webview team. this one is enough.

WebView already has an API:

https://developer.android.com/reference/android/webkit/HttpAuthHandler.html#useHttpAuthUsernamePassword()

isn't it suitable for this case?

Nate, please investigate and add a new API if useHttpAuthUsernamePassword does not work for this case.
 

ssivakumaraw@: I'm trying out your sample server (running both servers locally on my desktop, and trying to log in with an incognito window from the desktop), but I'm running into issues.

Upon opening the page, I'm prompted to provide a username and password, as expected. After entering credentials, the image doesn't properly load (I see the image-not-found icon). I'm then prompted to enter credentials 2 more times, each time one more image-not-found appears, until I'm no longer prompted for credentials and there are 3 of the icons on the page.

Is it correct for me to be prompted 3 times, and for the images to not render? This seems a little different from your steps above, and I'm not sure if it could be a factor in the issue. Thanks.

Hi @ntfschr

I noticed that the "image not displayed" issue is because of a content length mismatch issue. There must be a bug in the way the image is server by the web server. I will check that. But the authentication succeeds and the data is sent. For now, you can ignore the missing images. Firefox manages to display the images.

As for the 3 prompts, I need to check. I think it is expected. In the WebView, the onReceivedHttpAuthRequest is supposed to be called thrice (once for every resource), but since incorrect credentials are sent the first time, there will be three more prompts. Going by this, then 3 prompts are expected in the desktop browser (one for every resource). However Firefox prompts only once (I am guessing it sends cached credentials instead of prompting the user). I will check what is happening on the server side and confirm the expected behavior in a day. 

Thanks.

ssivakumaraw@, thanks for the quick reply. It's strange that chrome and firefox behave differently with the images, but aside from that it looks like the desktop behavior makes sense.

I'll look into spinning up the server sometime tomorrow and testing it with the android app you provided and see if I can reproduce those results. Let me know if you make any changes to the app or java servers in the meantime.

ssivakumaraw@, also I just took a look at the app code (haven't run it yet). I don't know much about domains and usernames, but are you intending to separate the domain and username with 1 backslash, or with 2? In your app code (authtestwebview/MainActivity.java) line 61, you're using 1 backslash, but in line 72 you're using 2 backslashes.

Was this intentional? If so, could you explain what's the intended behavior in these parts? Thanks.

Hi @ntfschr - The four slashes in username.split("\\\\") (line 72) is intentional because the input to split() is a regex and "\" needs to be escaped in a regex. 

Here's the background behind the code in onReceivedHttpAuthRequest - 

I want my WebView to authenticate to a bunch of sites on an Enterprise network. Some of these sites accept the username ONLY WITH domain ("acmeinc\johndoe"). Some of the sites accept the username ONLY WITHOUT domain ("johndoe"). 

Given this, I also want to implement a user-friendly auth cache in my app. The purpose of this cache is to store credentials for reuse to other sites. If the user enters credentials for one site, I wish to reuse it for other sites. But since I don't know which sites require the domain, I always try with "domain\username" first and if it fails, I try with "username" alone. The code tries to achieve this. 

Note that handler.useHttpAuthUsernamePassword() returns true when the previously used credentials to that host were successful. It also returns true for the first callback to that host.

This is all the information we have and this is insufficient when the WebView tries to authenticate to multiple resources in quick succession within the same host. There is no way to tell if the second callback is for a new resource or for a re-attempt for the first resource.

Please do let me know if you require any other info regarding the code. I am working on checking the web server behavior. Will update soon.

I have fixed the content length issue on the rs-server jar. You can download the updated jar from the same link - https://drive.google.com/open?id=0B215hnrL-RwOVTlmMGZFMkpBSmc

The images are still messed up, but at least they are displayed. 

I also tried to understand why there were 3 prompts on Chrome. Chrome creates 3 TCP connections and makes one HTTP request on each connection to get the 3 resources. The webserver requires correct authentication headers on all HTTP requests. Hence Chrome prompts the user 3 times (one for every connection). I see the same server side behavior for Firefox. It creates 3 TCP connections and sends a HTTP request on every connection. The server requests for authentication on all. However, Firefox seems to reuse the credentials it received from the user on the first prompt. It does not prompt the user again.

Hope this helps. Please do let me know if you any more questions.

ssivakumaraw@, our corporate network makes peer-to-peer connections very difficult to set up. I thought one of our tools would work for getting around this, but I believe it does not support HTTP Authentication.

A public-facing server might work better for me to reproduce and test the issue. Would httpbin.org/basic-auth/ be a suitable server alternative, or is there something special about how your servers work? (It seems like the site may be down right now, but hopefully it'll be running smoothly soon). Thanks.

ssivakumaraw@, is this still something that needs to be investigated? If so, are there are any end points at httpbin.org/ (or another public facing server) that would be suitable for testing this?

Hi @ntfschr, I could not dedicate time for this due to work. I will set this up in the next few days. 

Any further update on setting up a public facing server?

Closing this due to lack of response. Please ping this bug if there's still a need for this and I'll gladly investigate.