Our web application has user/password authentication. It runs on a web server which is secured itself with HTTP Basic Auth. This is just a temporary solution / workaround. The web application's authentication will be sufficient in future, but at the moment the web server Basic Auth prevents accessing the web application at all.
The web application returns status code 401 when not authenticated on application level. The WWW-Authenticate header defines a different realm, so the browser won't get confused between web server and web application authentication: If we didn't define a different realm the browser would throw away the web server credentials as soon as the application's 401 arrives.
So far so good. However our application has its own authentication dialog. For XHR requests we want to handle the 401 status on our own and need to prevent the browser's internal basic auth window. There is a simple trick for this: Just adjust authentication header (WWW-Authenticate) to use a custom auth method:
WWW-Authenticate: CustomBasic realm="myapp"
Whereby the web server returns:
WWW-Authenticate: Basic realm="webserver"
This works with Firefox but not with Chrome. Chrome ignores the realm when using CustomBasic and discards the credentials (user / password) for realm "webserver" as if we didn't define the realm "myapp" at all.
Do you know why? Do you know a solution with following requirements:
- Keep 401 status for both realms
- Do not show browser's basic auth window on application level (especially for XHR requests)
Yes I know we can simply workaround this by using different HTTP status codes on application level and handle them respecitvely. But if possible I want to keep the correct status codes 401. This could also be a valid use case, e.g. if you have two web applications accessible with two different URL paths on the same host.
