[Webkit-unassigned] [Bug 122952] [GTK][WPE] Support NTLM authentication

Thu Sep 10 05:33:28 PDT 2020

https://bugs.webkit.org/show_bug.cgi?id=122952

--- Comment #31 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Carlos Garcia Campos from comment #26)
> (In reply to Michael Catanzaro from comment #24)
> > (In reply to Carlos Garcia Campos from comment #23)
> > > It works for me with MiniBrowser.
> > 
> > Hm, yes, works in MiniBrowser for me too. Well, this is a one-liner to fix
> > in WebKit, then, unless we want all the plumbing to keep in disabled by
> > default. I'll ask Dan Winship to comment. His opinion was previously that we
> > should not enable NTLM by default, but it's clear that Firefox does, so
> > ?????.
> > 
> > Anyway, if I remove Epiphany's authenticate_cb (ephy-web-view.c), then it
> > works in Ephy too. The difference is that MiniBrowser doesn't implement the
> > authenticate signal. Epiphany returns TRUE to handle the authentication
> > event, then does a password manager lookup. If it has a stored
> > username/password, then it uses that; otherwise, it calls
> > webkit_authentication_request_authenticate() with an empty credential:
> > 
> > webkit_credential_new (" ", "", WEBKIT_CREDENTIAL_PERSISTENCE_NONE);
> > 
> > That normally triggers a retry, so the user gets the default auth prompt.
> > But with NTLM, it just results in an error. I guess we are actually
> > authenticating to the peer with empty username/password each time we display
> > a dialog for which we don't have username/password saved already.
> 
> That's probably a different behavior in libsoup rather than WebKit. Maybe we
> relied on specific auth type behavior for the api, I'll investigate.

I have debugged this and I think it's a problem specific to the test case, after a wrong auth the server responds with a 401, but without including the WWW-Authenticate header, so we don't know how to authenticate again, see:

> GET / HTTP/1.1
> Soup-Debug-Timestamp: 1599738858
> Soup-Debug: SoupSession 1 (0x55a42834e100), SoupMessage 1 (0x55a4283748c0), SoupSocket 1 (0x55a42869e0b0)
> Host: ntlm.herokuapp.com
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0 Safari/605.1.15
> Accept-Encoding: gzip, deflate
> Accept-Language: es-ES
> Connection: Keep-Alive

< HTTP/1.1 401 Unauthorized
< Soup-Debug-Timestamp: 1599738860
< Soup-Debug: SoupMessage 1 (0x55a4283748c0)
< Connection: keep-alive
< Www-Authenticate: NTLM
< Server: WEBrick/1.3.1 (Ruby/2.0.0/2014-09-19)
< Date: Thu, 10 Sep 2020 11:54:18 GMT
< Content-Length: 0
< Via: 1.1 vegur
< 

This is the initial request, we get Www-Authenticate: NTLM, so we create a new request with the Authorization.

> GET / HTTP/1.1
> Soup-Debug-Timestamp: 1599740315
> Soup-Debug: SoupSession 1 (0x55e751570100), SoupMessage 1 (0x55e7515968c0), SoupSocket 1 (0x55e7518c18b0), restarted
> Host: ntlm.herokuapp.com
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0 Safari/605.1.15
> Accept-Encoding: gzip, deflate
> Accept-Language: es-ES
> Connection: Keep-Alive
> Authorization: NTLM TlRMTVNTUAABAAAABYIIAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAwAAAA

< HTTP/1.1 401 Unauthorized
< Soup-Debug-Timestamp: 1599740316
< Soup-Debug: SoupMessage 1 (0x55e7515968c0)
< Connection: keep-alive
< Www-Authenticate: NTLM TlRMTVNTUAACAAAAAAAAACgAAAABAAAAAAAAAAAAAAA=
< Server: WEBrick/1.3.1 (Ruby/2.0.0/2014-09-19)
< Date: Thu, 10 Sep 2020 12:18:36 GMT
< Content-Length: 0
< Via: 1.1 vegur
< 

We don't emit the authenticate signal in this case because soup_auth_is_authenticated() is true (password_state != NONE and != REJECTED).

Now we send the actual Authorization with the credentials (I don't know much about NTLM, but I guess it works this way):

> GET / HTTP/1.1
> Soup-Debug-Timestamp: 1599740316
> Soup-Debug: SoupSession 1 (0x55e751570100), SoupMessage 1 (0x55e7515968c0), SoupSocket 1 (0x55e7518c18b0), restarted
> Host: ntlm.herokuapp.com
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Upgrade-Insecure-Requests: 1
> User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0 Safari/605.1.15
> Accept-Encoding: gzip, deflate
> Accept-Language: es-ES
> Connection: Keep-Alive
> Authorization: NTLM TlRMTVNTUAADAAAAGAAYAFAAAAAYABgAaAAAAAAAAABAAAAAAgACAEAAAAAOAA4AQgAAAAAAAAAAAAAAAYIAACAAVQBOAEsATgBPAFcATgApMxDEA8jwjLwJGQYSjqcaV+mht5VAw3RG6ixFGUNdZlYbPMMRYwTD6Tg6rz4ENxQ=

< HTTP/1.1 401 Unauthorized
< Soup-Debug-Timestamp: 1599740316
< Soup-Debug: SoupMessage 1 (0x55e7515968c0)
< Connection: keep-alive
< Server: WEBrick/1.3.1 (Ruby/2.0.0/2014-09-19)
< Date: Thu, 10 Sep 2020 12:18:36 GMT
< Content-Length: 39
< Via: 1.1 vegur
< 

And we get another 401, but this time with no Authenticate header, so we don't emit the authenticate signal again.

> > So, that's
> > not great. Ideally we would have some function to allow us to display
> > WebKit's default authentication prompt after the authenticate callback
> > without actually having to send credentials to the server.
> 
> I agree.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200910/7f921a61/attachment-0001.htm>