1858664 - Unable to sign in to tesco.com since the user agent rv was unfrozen

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Dave Townsend [:mossop]]

Since yesterday attempting to sign in to tesco.com (one of the largest UK grocery stores) has returned a 403 error page saying:

Access Denied

You don't have permission to access "http://www.tesco.com/account/login/en-GB?" on this server.

Reference #18.58847b5c.1697112509.17b8042c 

mozregression points to bug 1806690 as the cause so presumably tesco is doing some kind of UA detection here that isn't anticipating this change.

As one of the biggest grocery chains in the UK if we can't get this fixed on Tesco's end I think we need to either revert bug 1806690 or fix this some other way. Either way we should probably revert bug 1806690 for the time being or I won't be able to buy food 😀.

Comment 1

[James Graham [:jgraham]]

Seems like we need to ship an intervention for this.

Ksenia: I'm not sure where to look up who is managing the current interventions cycle, so since you're a) probably around and b) one of the people it might be, I randomly picked you (but please forward to someone else if that isn't true :) )

Comment 2

[Ksenia Berezina [:ksenia]]

Attachment: Screen Shot 2023-10-12 at 2.49.27 PM.png

We can add an intervention in bug1838841. Though I've tried to reproduce this in today's Nightly 120.0a1 (2023-10-12), and it works for me on both MacOS and Windows, with and without vpn to the UK. I'm able to login with a test account.

For reference, the user agent I was testing on MacOS is:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0

Hello Dave, I was wondering if it's still an issue for you? If it is, I can file a bug for an override (presumably we'll be replacing rv:* with rv:109.0).

Comment 3

[Chris Peterson [:cpeterson]]

If we see any other site breakage from rv:120.0, I can revert bug 1806690, restoring the rv:109.0 UA (perhaps forever).

An easy way to test different UA strings is to create a new string pref called general.useragent.override and set it to something like Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/120.0. I'm curious if changing rv:109.0 to rv:12 (or rv:12.0) also reproduces this error.

Comment 4

[Dave Townsend [:mossop]]

(In reply to Ksenia Berezina [:ksenia] from comment #2)

Created attachment 9358136 [details]
Screen Shot 2023-10-12 at 2.49.27 PM.png

We can add an intervention in bug1838841. Though I've tried to reproduce this in today's Nightly 120.0a1 (2023-10-12), and it works for me on both MacOS and Windows, with and without vpn to the UK. I'm able to login with a test account.

For reference, the user agent I was testing on MacOS is:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0

Hello Dave, I was wondering if it's still an issue for you? If it is, I can file a bug for an override (presumably we'll be replacing rv:* with rv:109.0).

Just tested and it is still failing for me.

(In reply to Chris Peterson [:cpeterson] from comment #3)

An easy way to test different UA strings is to create a new string pref called general.useragent.override and set it to something like Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/120.0. I'm curious if changing rv:109.0 to rv:12 (or rv:12.0) also reproduces this error.

rv:12, rv:12.0 both work fine. I wasn't completely thorough but it does look like anything >=120 causes the failure. If you go beyond 200 the server appears to start failing and even the homepage returns an error with the network disconnected before the TLS handshake completes.

Comment 5

[Dave Townsend [:mossop]]

(In reply to Dave Townsend [:mossop] from comment #4)

(In reply to Ksenia Berezina [:ksenia] from comment #2)

Created attachment 9358136 [details]
Screen Shot 2023-10-12 at 2.49.27 PM.png

We can add an intervention in bug1838841. Though I've tried to reproduce this in today's Nightly 120.0a1 (2023-10-12), and it works for me on both MacOS and Windows, with and without vpn to the UK. I'm able to login with a test account.

For reference, the user agent I was testing on MacOS is:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0

Hello Dave, I was wondering if it's still an issue for you? If it is, I can file a bug for an override (presumably we'll be replacing rv:* with rv:109.0).

Just tested and it is still failing for me.

(In reply to Chris Peterson [:cpeterson] from comment #3)

An easy way to test different UA strings is to create a new string pref called general.useragent.override and set it to something like Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/120.0. I'm curious if changing rv:109.0 to rv:12 (or rv:12.0) also reproduces this error.

rv:12, rv:12.0 both work fine. I wasn't completely thorough but it does look like anything >=120 causes the failure. If you go beyond 200 the server appears to start failing and even the homepage returns an error with the network disconnected before the TLS handshake completes.

Scratch that, I think I need to restart after changing the pref? Either that or I'm getting some inconsistent results here.

Comment 6

[Ksenia Berezina [:ksenia]]

Just tested and it is still failing for me.

Thanks for checking, I'll file a bug for an override then.

Scratch that, I think I need to restart after changing the pref? Either that or I'm getting some inconsistent results here.

general.useragent.override should work without restart, just page reload is enough

Comment 7

[Ksenia Berezina [:ksenia]]

Attachment: GitHub Pull Request

Comment 8

[Chris Peterson [:cpeterson]]

rv:12, rv:12.0 both work fine. I wasn't completely thorough but it does look like anything >=120 causes the failure. If you go beyond 200 the server appears to start failing and even the homepage returns an error with the network disconnected before the TLS handshake completes.

I'm not able to reproduce that behavior on the tesco.com homepage, but I'm in the US and not using a VPN. Perhaps I'm redirected to a different server or site.

Comment 9

[Ksenia Berezina [:ksenia]]

We shipped an override in bug1838841. Dave, could you please check if it fixed the problem for you, in Nightly?

Comment 10

[Dave Townsend [:mossop]]

This still appears to be broken

Comment 11

[Ksenia Berezina [:ksenia]]

(In reply to Dave Townsend [:mossop] from comment #10)

This still appears to be broken

Thanks for checking. I tried a couple times today and was able to reproduce it actually, with a Windows UA and a vpn to Manchester.

Looks like Firefox version is also affecting it, and not just rv segment. I'm getting the error with anything higher than Firefox/120.0 .

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/120.0 and lower works
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/121.0 and up fails

both of these fail:
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:119.0) Gecko/20100101 Firefox/119.0
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0

So I think changing the intervention to a hardcoded string, like Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/120.0 would make the most sense.

Comment 12

[Ksenia Berezina [:ksenia]]

I've updated the override in bug1862225 and Dave confirmed that it works for him, so I think we can close this.