Bug 260538 – [GTK] Fails to open tesla.com: website is unusable except when web inspector is open, "Access Denied"

• Component: WebKitGTK
• Status: NEW

[Milan Crha]

Trying to open tesla.com using Epiphany:

epiphany-45~beta-1.fc39.x86_64
epiphany-runtime-45~beta-1.fc39.x86_64
webkit2gtk4.0-2.41.91-1.fc40.x86_64
webkit2gtk4.1-2.41.91-3.fc40.x86_64
webkit2gtk4.1-doc-2.41.91-3.fc40.noarch
webkitgtk6.0-2.41.91-3.fc40.x86_64

yields to an error page:

   Access Denied

   You don't have permission to access "http://www.tesla.com/" on this server.

despite the address line reads:

   https://www.tesla.com/

aka the address line claims to be "secure", but the error says it is "insecure". It does not help to type "https://...." directly into the address line.

[Michael Catanzaro]

This website works fine for me.

The Access Denied error means exactly what it says: you personally are prohibited from accessing the website. Your IP address might be banned, for example. It's not generally possible to do anything about this without asking the website why they are blocking you.

[Milan Crha]

The catch up is that using Firefox works with no problem. I'm not aware of any special settings on the Epiphany side, though if I did anything I forgot of it already. This is only a rawhide virtual machine, even I can reproduce also on a Fedora 38.

Do you think any site data (aka cache/cookies) can be involved here? This is the first time accessing the tesla.com from this machine. I had a problem to access some subsites of otherwise working sites too, which cured once I deleted the cache (through the Epiphany interface) after upgrade from Fedora 37 to 38 (which I hoped would cure my problems, because the site worked on some other virtual machine with Fedora 38, but it did not).

[Kdwk]

https://tesla.com is reachable on my machine but the website is not rendered. There is no error in the terminal and only a 404 favicon not found in the web console. Meanwhile Firefox can reach and render the website.

WebKitGTK 2.41.91

(Nvidia)

[Michael Catanzaro]

I don't know, Milan. All I know is that "Access Denied" means what it says.

So yesterday when I tested this, I had the web inspector open to check for errors. It seems that was actually required for the website to display. telsa.com is very broken: scrolling does not work, and images display only if the web inspector is open. Those are surely bugs on our side that we need to fix.

But I'm skeptical that they are related to the "Access Denied" issue. You can check if cache or cookies are involved by using an incognito window.

[Milan Crha]

I get the same error when using the incognito window, thus you are right, it's not a cache problem.

I do not make it work even with the Inspector shown (in the incognito window). The Network tab shows the GET was done with scheme "https:", no idea what failed here.

If I understand it correctly, the error page is generated by the server, right? It looks like that to me, but I'm not sure. Being it so, I'd guess the server has disabled insecure connections and allows only secure connections. The Epiphany shows in the address bar that the address in use is secure (httpS), still it looks like WebKit does something with insecure connection, which is rejected by the server, and it gets to the GUI.

I tried:
   $ wget https://www.tesla.com
   --2023-08-23 16:13:07--  https://www.tesla.com/
   Resolving www.tesla.com (www.tesla.com)... 23.75.66.131, 2a02:26f0:dc:18a::700, 2a02:26f0:dc:181::700
   Connecting to www.tesla.com (www.tesla.com)|23.75.66.131|:443... connected.
   HTTP request sent, awaiting response... ^C

and it did not went further, thus I Ctrl+C it. Then I tried:

   $ curl -v --http1.1 https://www.tesla.com

also times out, but using --http2 returns the "Access Denied" page. Firefox also uses HTTP/2, but I do not decipher much from its Network logs, I'm sorry.

[Kdwk]

Created attachment 467396 [details]
Screen recording showing bug

Can confirm that I am able to see the site content when web inspector is opened, and that even then I am unable to scroll

[Michael Catanzaro]

Scrolling seems to work roughly half the time (only when the web inspector is opened), broken half the time.

Milan, I'm pretty sure the server is just blocking you specifically. We probably can't do anything about Access Denied unless Tesla is willing to tell you why you are blocked.

[Milan Crha]

It looks like they are filtering on the User-Agent and Accept-Language headers, because I've been trying the headers used by the Firefox and when I include these two (only both of them work) the curl command returns a valid page, otherwise I get the "Access Denied" response. The full command I use, which works:

   curl -v --http2 https://www.tesla.com -H "Accept-Language: en-US,en;q=0.5" -H "User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0"

[Michael Catanzaro]

Maybe we need a quirk for tesla.com to send an English-only Accept-Language header? I won't hesitate to add such a quirk if required. tesla.com should not discriminate if it wants to receive accurate headers from WebKit.

Can you check Preferences -> Languages and show when languages you have configured? I couldn't find an option for Czech, so I tried Chechan instead :D but tesla.com seemed to be OK with that.

[Milan Crha]

My system language is en_US, which the Preferences->Languages interprets as "en-US, en".

Maybe I did not express myself well, I needed to add both Accept-Language and User-Agent to the curl command to make it work, not only one of them.

Could they limit access based on the GEO location? That would be quite awkward from them.

Thinking of it more, either you can add a site quirk, or feel free to close this as "not WebKit". It's nice tesla.com "supports" Firefox, but it's bad they limit browsers they do not know about, furthermore in an unpleasant way (meaningless/unhelpful error message).

[Michael Catanzaro]

(In reply to Milan Crha from comment #10)
> My system language is en_US, which the Preferences->Languages interprets as
> "en-US, en".
> 
> Maybe I did not express myself well, I needed to add both Accept-Language
> and User-Agent to the curl command to make it work, not only one of them.

I understood this. But Epiphany already sends both headers. (Its Accept-Language header doesn't look the same as other browsers' headers, but we shouldn't need to change that.)

> Could they limit access based on the GEO location? That would be quite
> awkward from them.

Of course. They can block you for any reason or no reason. Without a more specific error message, we have no way to know.
 
> Thinking of it more, either you can add a site quirk, or feel free to close
> this as "not WebKit". It's nice tesla.com "supports" Firefox, but it's bad
> they limit browsers they do not know about, furthermore in an unpleasant way
> (meaningless/unhelpful error message).

But we can only add a quirk if you can figure out how to make them not block you. E.g. if changing Accept-Language or changing user agent header works, then I can add a quirk for that, sure. But it sounds like we still don't know how to make it work.

[Milan Crha]

Looking in the web inspector from Epiphany, I see the request has:

   User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.4 Safari/605.1.15
   Accept-Language: en-US,en;q=0.90

and the response contains header:

   permissions-policy: interest-cohort=()
   Server: AkamaiGHost
   strict-transport-security: max-age=15768000

if it means anything to you. Other response headers look boring/unrelated.

The used Accept-Language headers looks fine, I can make it work with it and "correct" User-Agent.

I played a bit with the User-Agent header and they are very strict. Changing just the Firefox version at the end of the string (from comment #8) can cause "Access Denied" error. I tried `Firefox/215.1` and they rejected me.

[Michael Catanzaro]

Found the same bug on Google Drive. I wanted to watch a video stored on Google Drive, but the website was unusable except when I open the web inspector.