[Webkit-unassigned] [Bug 191858] New: Unexpected User-Agent on redirect

[bugzilla-daemon at webkit.org]

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

            Bug ID: 191858
           Summary: Unexpected User-Agent on redirect
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jmason at ibinx.com

WebKitGTK: 2.22.3
Epiphany:  3.30.2

It seems the User-Agent quirk mechanism is using the URL of a request to decide which quirk to send, not only for the original request, but also for any associated redirects.  As a result, in some situations, sites which should not receive a UA quirk receive it, and sites which should receive one do not.

This manifests itself readily during Google OAuth, in the case when Google challenges the user for credentials.

Below is an extract from a service provider web server log for a user who is attempting to login via Google SSO.  (I have suppressed the client IP address and truncated the query strings for readability):

> x.x.x.x - - [16/Nov/2018:14:37:31 +0100] "GET /kzsu/ssoLogin.php HTTP/1.1" 307 - "https://zookeeper.ibinx.com/kzsu/?" "Mozilla/5.0 (X11; SunOS i86pc) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Safari/605.1.15 Epiphany/605.1.15"
> x.x.x.x - - [16/Nov/2018:14:37:36 +0100] "GET /kzsu/ssoLogin.php?state=0ea73ed9f8965966b201f5b70355795c... HTTP/1.1" 307 - "https://accounts.google.com/ServiceLogin?continue=https..." "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Safari/605.1.15"
> x.x.x.x - - [16/Nov/2018:14:37:37 +0100] "GET /kzsu/?action=loginValidate&session=c8c39681f2db99f849998349... HTTP/1.1" 200 1665 "https://accounts.google.com/ServiceLogin?continue=https..." "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Safari/605.1.15"


The first request above results in a redirect to Google.  The second request is the redirect from Google, which in turn results in an intra-site redirect (the third request).  We can see that Google challenged the user because the value of the Referer changed.

Observed behaviour:  UA on the second and third request is the `LinuxDesktopPlatform` quirk.

Expected behaviour: UA on the second and third request should match the first one (i.e., the normal UA)


As a counter example, if the user is already logged into Google, there is no challenge at Google, only a redirect:

> x.x.x.x - - [16/Nov/2018:16:51:04 +0100] "GET /kzsu/ssoLogin.php HTTP/1.1" 307 - "https://zookeeper.ibinx.com/kzsu/?session=" "Mozilla/5.0 (X11; SunOS i86pc) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Safari/605.1.15 Epiphany/605.1.15"
> x.x.x.x - - [16/Nov/2018:16:51:05 +0100] "GET /kzsu/ssoLogin.php?state=6efaaea080fb97213d27d41266a41347... HTTP/1.1" 307 - "https://zookeeper.ibinx.com/kzsu/?session=" "Mozilla/5.0 (X11; SunOS i86pc) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Safari/605.1.15 Epiphany/605.1.15"
> x.x.x.x - - [16/Nov/2018:16:51:05 +0100] "GET /kzsu/?action=loginValidate&session=12c17d8a4a222f23b8299942cee5347b HTTP/1.1" 200 1665 "https://zookeeper.ibinx.com/kzsu/?session=" "Mozilla/5.0 (X11; SunOS i86pc) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Safari/605.1.15 Epiphany/605.1.15"


Above are the same three requests as the first log extract, except in this case, the Referer on the second and third requests is the original URL.  This indicates Google did not challenge the user for credentials.

In this case, the UA is correct for all three requests (though likely, the real UA and not the quirk is presented to Google).


Expected behaviour:  In all cases, the UA quirk, if any, that is presented to a site should be determined by that specific target URL, and not the original URL from which the request was redirected.

-- 
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/20181120/9b8b3660/attachment.html>