Closed Bug 1660446 Opened 4 years ago Closed 3 years ago

Unable to login with Facebook /Google account on we.hamropatro.com with ETP enabled

Categories

(Core :: Privacy: Anti-Tracking, defect, P2)

Desktop
All
defect

Tracking

()

VERIFIED FIXED
95 Branch
Tracking Status
firefox87 --- wontfix
firefox95 --- verified

People

(Reporter: ciprian, Assigned: twisniewski)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Environment:
Browser / Version: Firefox Nightly 81.0a1 (2020-08-20)
Operating System: macOS 10.15.6/Windows 10 Pro/Ubuntu 20.04 LTS

STR:

  1. Access https://we.hamropatro.com/login?redirectURL=/home.
  2. Click the login with Google/Facebook button.
  3. Observe the behavior.

Expected result:
The platform-specific authentication process is initiated and the user is logged in after finalizing the authentication.

Actual result:
The user is not logged in.

Notes:

  1. The user is logged in when ETP is disabled for the authentication process.
  2. The issue is not reproducible on Chrome 84.0.4147.135 .

This breakage is caused by dFPI. I can fix this issue as I change the cookie behavior to 4.

According to the console message, the login process will try to access the cookies on the site https://hamropatro.firebaseapp.com/. And the storage is partitioned since it is a third-party context. And I guess that's the place where the login data is stored. So the login fails.

Severity: -- → S3
Priority: -- → P2

A further investigation about this login issue. I found that the login process would first redirect to the https://hamropatro.firebaseapp.com/ and it will try to log in Google/Facebook by another redirect. Once the login completes, it will redirect back to https://hamropatro.firebaseapp.com/ and the login data is stored there. And, finally, it will redirect back to the https://we.hamropatro.com/login and then try to get the login data from https://hamropatro.firebaseapp.com/.

It appears that the redirect heuristic doesn't apply here since the login process doesn't require a user interaction on https://hamropatro.firebaseapp.com/. So, it won't get the storage access.

The issue still occurs with ETP - Standard and Strict, sign in with Google/Facebook is not performed.
https://prnt.sc/y0wtt1

Tested with:
Browser / Version: Firefox Nightly 87.0a1 (2021-02-01)
Operating System: Windows 10 Pro

I've reached out to them about the issue via email.

Assignee: nobody → pbz
Status: NEW → ASSIGNED
Assignee: pbz → twisniewski
Pushed by twisniewski@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a874e44886c6
Shim requestStorageAccess for Hamropatro FB/Google oauth logins; r=pbz,ksenia,webcompat-reviewers
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch

Hi, thank you for landing this.

I have another request, since we have many other service that live on the same domain in different subdomains, would it be possible to have wildcard(://.hamropatro.com/*) configuration to have access to storage of https://hamropatro.firebaseapp.com?

Thank you1

(In reply to Dinesh Bhattarai from comment #8)

Hi, thank you for landing this.

I have another request, since we have many other service that live on the same domain in different subdomains, would it be possible to have wildcard(://.hamropatro.com/*) configuration to have access to storage of https://hamropatro.firebaseapp.com?

Thank you1

Hi! We don't normally add wildcard exceptions like that. You can read about our policy here.
If hamropatro.firebaseapp.com needs access to it's first party storage on hamropatro.com it can call the Storage Access API. In the patch attached to this bug, we do it on behalf of the site to un-break it. However, normally the site should request storage access itself, e.g. prior to login.

Verified as fixed on Firefox Nightly 95.0a1 on Windows 10 x64, macOS 11.6 and on Ubuntu 20.04.

Status: RESOLVED → VERIFIED
See Also: → 1782772
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: