Bug 191858 - Unexpected User-Agent on redirect
Summary: Unexpected User-Agent on redirect
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-20 03:15 PST by Jim Mason
Modified: 2018-11-22 02:46 PST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Mason 2018-11-20 03:15:06 PST
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.
Comment 1 Michael Catanzaro 2018-11-21 11:36:38 PST
(In reply to Jim Mason from comment #0) 
> 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)

Just to confirm: the second and third requests are requests to your server, which had been first made to Google and then later redirected?

I think I agree. The quirk should be changed to match the new host after the redirect.
Comment 2 Jim Mason 2018-11-22 02:46:42 PST
(In reply to Michael Catanzaro from comment #1)
> Just to confirm: the second and third requests are requests to your server,
> which had been first made to Google and then later redirected?

That is correct.  However, in the first log extract, Google initiates the redirect (it is not merely a redirect of my initial request).  It is only in this case that my server sees the UA quirk intended for Google.