Closed Bug 1638673 Opened 4 years ago Closed 4 years ago

Cannot log into PlayStation Store

Categories

(Core :: Networking: HTTP, defect, P3)

Product:
Core
Component:
Networking: HTTP
Version:
77 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: frederick888, Unassigned)

References

Details

Attachments

(1 file)

Screenshot_20200517_155854.png
220.50 KB, image/png
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

  1. Visit https://store.playstation.com/
  2. Sign in

Actual results:

  1. It shows The connection to the server timed out.
  2. POST request to https://ca.account.sony.com/api/v1/ssocookie fails with HTTP 403

Expected results:

Log in successfully and redirects back to Store front page.

Using the same network and PC, I can log in using Google Chrome. On my phone (iOS) using Firefox I can log in without any hiccups as well.

I'm running Firefox 77.0b6 under Linux. So far what I've tried:

  1. Disabling Enhanced Tracking Protection for store.playstation.com social.playstation.com smetrics.aem.playstation.com my.playstation.com my.account.sony.com ca.account.sony.com auth.api.sonyentertainmentnetwork.com
  2. Disabling Enhanced Tracking Protection completely
  3. Safe mode
  4. Clean new profile with Enhanced Tracking Protection disabled
  5. Proxy all Sony domains to another country
  6. Proxy and disabling Enhanced Tracking Protection together
  7. Firefox 76.0.1 in a Windows Server box in a different country
  8. Changing my UA to Chrome 81 for Windows
  9. Different PSN accounts for different countries/regions

I made sure all the Sony and PlayStation cookies were deleted every time before starting a new test.

I posted this on Reddit and it seems this happens on macOS as well.

And by the way I've got network.cookie.sameSite.laxByDefault = false so it doesn't seem to be related to bug 1626696.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Networking: HTTP
Product: Firefox → Core

Hello Reporter,
Thanks for reporting this.
I'd like to ask some question first:
(a)
In your description, POST request to https://ca.account.sony.com/api/v1/ssocookie fails with HTTP 403.
Does it come with a different result from the browsers which are able to log in?

(b)
Could you try again for Firefox Nightly in desktop? As I know we may have fixes in current Nightly.

Flags: needinfo?(frederick888)

I'm having the same issue and I've done some investigation into this. From the looks of it, at least for me, it's caused by the faulty web application firewall in Akamai. When the login succeeds the response comes with 200, proper CORS headers, token in the body and it has Server: nginx, but when it fails with 403 the response it has no CORS headers and Server: AkamaiGHost (one time I got AkamaiNetStorage, but I'm not sure if that was under the same conditions). During my testing across different OSes I've found that:

  • Firefox 76.0.1 from the host system (Linux) fails with 403, but I was able to login 1 time successfully using the freshly created profile, any further attempts with the fresh profile failed
  • Firefox 76.0.1 from the virtual Windows 10 machine (same host, so the same IP address) sometimes works, mostly fails
  • Firefox 76.0.1 from the virtual macOS machine (again, same host) works all the time

(In reply to Junior from comment #4)

(a)
In your description, POST request to https://ca.account.sony.com/api/v1/ssocookie fails with HTTP 403.
Does it come with a different result from the browsers which are able to log in?

I am able to log in with Google Chrome 83.0.4103.61 under Linux.

Under Chrome it's also a CORS OPTIONS request followed by a POST one except that POST https://ca.account.sony.com/api/v1/ssocookie returns 200 instead of 403.

(b)
Could you try again for Firefox Nightly in desktop? As I know we may have fixes in current Nightly.

I just tested on 78.0a1 (2020-05-26) and got the same result.

Flags: needinfo?(frederick888)

Junior, can you investigate this?

Flags: needinfo?(juhsu)

(In reply to Pavel from comment #5)

I'm having the same issue and I've done some investigation into this. From the looks of it, at least for me, it's caused by the faulty web application firewall in Akamai. When the login succeeds the response comes with 200, proper CORS headers, token in the body and it has Server: nginx, but when it fails with 403 the response it has no CORS headers and Server: AkamaiGHost (one time I got AkamaiNetStorage, but I'm not sure if that was under the same conditions). During my testing across different OSes I've found that:

  • Firefox 76.0.1 from the host system (Linux) fails with 403, but I was able to login 1 time successfully using the freshly created profile, any further attempts with the fresh profile failed
  • Firefox 76.0.1 from the virtual Windows 10 machine (same host, so the same IP address) sometimes works, mostly fails
  • Firefox 76.0.1 from the virtual macOS machine (again, same host) works all the time

Thanks for the tremendous finding, Pavel!
Could you specify what exactly the CORS header is?
I'm also wondering if we have different request headers between the success and failure cases.

You mentioned about the CORS header. Maybe check if we have errors in the web console?

Flags: needinfo?(juhsu) → needinfo?(pavel.procopiuc)

These are the headers when a login is denied

HTTP/1.1 403 Forbidden
Server: AkamaiGHost
Mime-Version: 1.0
Content-Type: text/html
Content-Length: 297
Expires: Wed, 03 Jun 2020 08:00:23 GMT
Date: Wed, 03 Jun 2020 08:00:23 GMT
Connection: close
Set-Cookie: <cut>

The console shows "CORS header 'Access-Control-Allow-Origin' missing" error.

These are when it's successful:

HTTP/1.1 200 OK
Server: nginx
Content-Type: application/json;charset=UTF-8
X-Psn-Request-Id: <cut>
X-Psn-Correlation-Id: <cut>
X-RequestId: <cut>
X-CorrelationId: <cut>
X-Content-Type-Options: nosniff
Access-Control-Allow-Origin: https://my.account.sony.com
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: X-Psn-Request-Id,X-RequestId,X-Content-Type-Options,X-NPSSO-TOKEN,X-CorrelationId,X-Psn-Correlation-Id,X-NP-GRANT-CODE,Location
p3p: CP="This site does not have a P3P policy."
x-wily-info: Clear guid=<cut>
x-wily-servlet: Encrypt1 <cut>
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Expires: 0
Content-Length: 186
Date: Wed, 03 Jun 2020 08:47:39 GMT
Connection: keep-alive
Set-Cookie: <cut>

But note that missing CORS headers are just the symptom, the problem seems to be caused by the intermediate server (AkamaiGHost) which blocks the request and returns a generic 403 page without any service specific headers.

Flags: needinfo?(pavel.procopiuc)

Just in case anyone needs a kind of workaround. After the successful login (e.g. in Chrome) you can transfer the cookie named npsso with domain ca.account.sony.com to Firefox and it will restore the login session there.

@Pavel I did that but was logged out after a few days. Perhaps the cookie is supposed to be rotated.

But note that missing CORS headers are just the symptom, the problem seems to be caused by the intermediate server (AkamaiGHost) which blocks the request and returns a generic 403 page without any service specific headers.

You are right. Those CORS headers are for browsers to judge if we should pop the response or not.

You mentioned that we can login the very first time, right?
I'm wondering if we have anything different from the request headers in the POST for
(a) success case in Firefox
(b) fail case in Firefox
(c) success case in other browsers

I'm wondering if it's just cookies. If it is, a new profile/private mode should work, which contradicts comment 1.

And does comment 2 work for you, Pavel?

Flags: needinfo?(pavel.procopiuc)

By the way, Comment 2 works well to me for lastest Nightly 2020-06-03, and failed in nightly for the one in comment 6.

However, when I did the mozregression, I figure out comment 1 happen pretty random with clean profile with samesite off on mac.
The regression window is https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=31180a6246b9d8886e9de6600efcf0280211108d&tochange=40150e24e05f9ae3736db83b9b380047404650ad for me, which is not possible to cause this regression.

I compare with the request headers, with
(a) success case in Firefox
(b) fail case in Firefox

I didn't see much difference between them. One might be X-Referer-Info which is not controlled by browsers.
Reporter, could you test again for the latest nightly?

Flags: needinfo?(pavel.procopiuc) → needinfo?(frederick888)

Forget to mention, another difference is comment 10. Let's see if latest nightly works or not.

I can now log in using Firefox Developer Edition 78.0b2 without any problem.

In terms of Nightly 79.0a1 however, https://ca.account.sony.com/api/v1/ssocookie is now ok and I can get the npsso cookie, but after I'm redirected to the store front page, it still shows that I'm not logged in. If I click on the sign-in button again, it then basically just refreshes the page and then nothing happens.

Flags: needinfo?(frederick888)

(In reply to frederick888 from comment #15)

I can now log in using Firefox Developer Edition 78.0b2 without any problem.

In terms of Nightly 79.0a1 however, https://ca.account.sony.com/api/v1/ssocookie is now ok and I can get the npsso cookie, but after I'm redirected to the store front page, it still shows that I'm not logged in. If I click on the sign-in button again, it then basically just refreshes the page and then nothing happens.

it works for me to turn off pref network.cookie.sameSite.laxByDefault
Is it not the case at your side?

Flags: needinfo?(frederick888)

fwiw network.cookie.sameSite.laxByDefault is enabled in nightly only

(In reply to Junior from comment #17)

fwiw network.cookie.sameSite.laxByDefault is enabled in nightly only

Ah yup, you were right. After turning off network.cookie.sameSite.laxByDefault it's working in Nightly as well! Thank you and I guess this issue has been resolved!

Flags: needinfo?(frederick888)

Thanks for your great support, frederick888 and Pavel!
Given Nightly work well with dup of bug 1626696, I'm going to close this.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME

Well, for me, neither the new stable (77.0.1) nor developer version (78.0b2) nor the current nightly (79.0a1) worked. Using a clean profile with all of them result in the same 403 issue when POSTing to https://ca.account.sony.com/api/v1/ssocookie.

Here are request headers (as copied from the network inspector in dev tools after switching to raw headers) for successful login from the macOS VM:

Host: ca.account.sony.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:76.0) Gecko/20100101 Firefox/76.0
Accept: */*
Accept-Language: nl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://my.account.sony.com/
Authorization: Bearer <cut>
X-Origin-ClientId: <cut>
X-CorrelationId: <cut>
X-Referer-Info: https://my.account.sony.com/central/signin/?<cut>
Content-Type: application/json; charset=UTF-8
Content-Length: 1229
Origin: https://my.account.sony.com
Connection: keep-alive
Cookie:  <cut>

Success from Google Chrome:

POST /api/v1/ssocookie HTTP/1.1
Host: ca.account.sony.com
Connection: keep-alive
Content-Length: 1232
Authorization: Bearer <cut>
X-Referer-Info: https://my.account.sony.com/central/signin/?<cut>
X-CorrelationId: <cut>
X-Origin-ClientId: <cut>
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36
Content-Type: application/json; charset=UTF-8
Accept: */*
Origin: https://my.account.sony.com
Sec-Fetch-Site: same-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://my.account.sony.com/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cookie: <cut>

Here are the failing ones (from nightly, fresh profile):

POST /api/v1/ssocookie HTTP/1.1
Host: ca.account.sony.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0
Accept: */*
Accept-Language: nl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://my.account.sony.com/
Authorization: Bearer <cut>
X-Origin-ClientId: <cut>
X-CorrelationId: <cut>
X-Referer-Info: https://my.account.sony.com/central/signin/?<cut>
Content-Type: application/json; charset=UTF-8
Content-Length: 1371
Origin: https://my.account.sony.com
Connection: keep-alive
Cookie: <cut>
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site

(In reply to Pavel from comment #20)

Well, for me, neither the new stable (77.0.1) nor developer version (78.0b2) nor the current nightly (79.0a1) worked. Using a clean profile with all of them result in the same 403 issue when POSTing to https://ca.account.sony.com/api/v1/ssocookie.

What date of nightly were you testing on?
If it's later than 2020-06-03, and the rules in comment 10 are true for all the requests in the three cases (I can't tell since it's censored), we might need HTTP log to move forward.
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
Please append cookie:5 if your about:networking doesn't contains this in the module.

If you want, you can send the log file directly to me for privacy.

Flags: needinfo?(pavel.procopiuc)

Hi, thank you, I've sent the logs to your e-mail address.

Flags: needinfo?(pavel.procopiuc)

This happens to me pretty randomly.
The POST can succeed or fail without cookies.
Hence cookie is not the main reason.
Comment 10 might have some effect inside the network, but not the root cause here.

The 403 is the reason for login failure.
I check the js inside and I'm kinda sure that the responded json is the key to move forward.

I was suspecting the routing inside the server given the server responds "You don't have permission to access on this server." on that POST request and the page shows "The connection to the server timed out." immediately.
The resolved IP is the same, headers are equivalent in some sense but comes different results.

Mike, could you mention this to sony with this?

Flags: needinfo?(miket)
Priority: -- → P3

I'll see if I can dig up some contacts.

Flags: needinfo?(miket)

Firefox 80.0.1 (x64) still cannot login with same error. Sometimes firefox in virtual machine worked. Other browsers never has this problem.

I couldn't login on PSN since months with Firefox. (Timeout error) I tried everything, like in the second post above. Nothing worked.
The only thing that helped me was to refresh Firefox. Since then it logs in on PSN without a problem.

I'm still getting this with Firefox 86 on Ubuntu. In a regular browser tab, the login fails every time. Clearing cookies, disabling enhanced tracking protection, and disabling extensions have no effect.

However, the site also consistently works for me in private browsing mode.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: