Basic/Digest Auth Navigations have no request/response headers
Problem
To properly implement https://gitlab.com/gitlab-org/gitlab/-/issues/331221 we need to know if the authentication used by the target website
is basic or digest authentication. Unfortunately, Chromium disallows access to the Authorization (client) and WWW-Authenticate (server) headers.
Instead we must handle the fetch.authRequired event dynamically.
To reduce complexity of our authentication process we opt'd to not signal the exact authentication information back to the authentication service. However, without this information, we are unable to determine which of the two was selected. Additionally, our authentication report lacks evidence that this header was ever included, making for a poor UX.
Possible Solutions
Getting the authentication data to the AuthService/Authenticator
Save the Auth data as a property in the Browser
We could save this information in the browser as a property, then expose a getter to retrieve it. This would need to be locked with a mutex to protect
against possible race conditions. The basic_digest.go authenticator would then call this getter after LoadLoginPage was called to retrieve the details
and augment the NavigationResult with the details.
Injecting new BrowserEventHandler
Expose a new method on the browser which allows us to inject new BrowserEventHandler. This would allow for the basic_digest.go authenticator to
inject a custom fetch.authRequired event handler and store the information necessary prior to returning from LoadLoginPage. We could then augment
the NavigationResult with a synthetic response header.
Initiate a new Go http.Client request
Inside of basic_digest.go we could create a Go http.Client and inject the proxy details. When LoadLoginPage
is called, we would let the browser handle the request as usual, but then create a secondary request using the Go client to read the request details which
should include the header information we need. This information could then be added to the NavigationResult.