Investigate and Support logging into accounts.google.com with Google Chrome

[AtofStryker]

What would you like?

I would like to be able to log into accounts.google.com as an identity provider within cypress using Google Chrome as my browser. Google login should work with the merging of #22958 and #22963 inside of Cypress when using Electron and Edge.

Why is this needed?

No response

Other

No response

[AtofStryker]

We have been investigating this issue for a few weeks now. From what it looks like, visiting https://accounts.google.com/o/oauth2/auth has some special origin isolation around it. The frame is unable to communicate to spec bridges of same origin, even with chrome-web-security turned off as well as site-isolation-trials, but did not see a difference.

We initially thought this error was scripting related, as it looked like the window objects were being edited upon visit, but were able to rule this out by setting up an empty cy.fixture with only injection code and returning the fixture through cy.intercept when we would visit https://accounts.google.com/o/oauth2/auth.

This prompted some investigation into chromium and chrome canary to see if the issue persisted in these browsers. The issue persists in chromium, chrome, chrome canary, but not in Microsoft Edge or Electron. Since chromium is open source, we decided to the look into the code and found that Google does indeed have its own list of site isolations when building chromium with the USE_INTERNAL_ISOLATED_ORIGINS flag. This seems suspect as Google own browsers have this issue, but other consumers of chromium do not, and the special list is needed when building.

However, it looks like this behavior might be configurable through site isolation flags, even though this didn't seem to yield results the first time. We tried running with the --disable-features=IsolateOrigins,site-per-process in addition to --disable-site-isolation-trials and disable-web-security without luck.

Currently going to build the chromium binary on MacOS without the special list and point cypress to the binary and see what happens 😬 .

[AtofStryker]

We also don't believe SPDY/HTTP2 headers are playing a part or issue

[AtofStryker]

I was able to build the chromium binary, which took a few hours and unfortunately yielded the same results in development mode as chrome 😢 . I also tried passing some additional flags into chromium that I thought would be helpful:

   '--no-sandbox-and-elevated'
   '--no-zygote-sandbox'
   '--disable-web-security'
   '--allow-running-insecure-content'
   '--disable-features=IsolateOrigins,site-per-process'
   '--webview-disable-safebrowsing-support'
   '--data-reduction-proxy-server-experiments-disabled'
   '--disable-arc-opt-in-verification'
   '--disable-auto-wpt-origin-isolation'
   '--disable-client-side-phishing-detection'
   '--disable-domain-reliability'
   '--disable-domain-blocking-for-3d-apis'
   '--disable-enterprise-policy'
   '--disable-extensions-file-access-check'
   '--disable-field-trial-config'
   '--disable-gaia-services'
   '--disable-gesture-requirement-for-presentation'
   '--disable-namespace-sandbox'
   '--disable-oor-cors'
   '--disable-origin-trial-controlled-blink-features'
   '--disable-permissions-api'
   '--force-disable-variation-ids'

After adding the flags and verifying they were passed in via the CLI, the results were still the same.

[AtofStryker]

The only other avenue I can think of that might be worth comparing to figure out the "what" here is comparing the GN builds of MS Edge (I believe this is private) and Electron to see how they contrast with the de-facto chromium build configuration. [Brave]() might also be worth a look. The ungoogled-chromium project also gets past the implicit window issues with these build args. My guess is it has to do with a built dependency within chromium or something that is configurable with a build flag that isn't configurable at launch/run time.

[mjhenkes]

We should consider this when we offer browser binaries (https://github.com/cypress-io/cypress/issues/19241). It's a reason why we might want to build the chromium binary ourselves instead of just using the pre-built one.

[idanElitzur]

Do you have any followup about this issue? i'm dealing with the same issue too

[AtofStryker]

Hey @idanElitzur. Sorry that you are also running into this issue. The main blocker for this issue inside of chrome is that the iframe that contains Cypress is not an exact match on same-origin policy, but matches the origins super domain. The document.domain property doesn't seem to be respected in regards to this, and is unique to chrome, chromium, and canary.

The good news is we have recently proven that making these iframes same-origin solves this issue, and will likely have this issue resolved in the next few weeks once we agree on implementation and ship the code 😃 .

[AtofStryker]

related to #23814

[idanElitzur]

Thanks a lot @AtofStryker That is a really good news and hope it will be solved out ASAP! 🙏

Should I do it by Electron in a meantime or by some API request under the hood? The electron able to cross the origin and reach the actions inside it but it didn't take the session cookies before the redirection and can't complete this flow.

[AtofStryker]

I hope it is out soon as well! In the meantime approach, I replied here to hopefully provide some type of workaround. Not ideal at all, but this won't be an issue for long!

[idanElitzur]

Hey @AtofStryker Is this fixed already as part of v10.9.0?

[AtofStryker]

@idanElitzur This isn't released yet, but should be supported experimentally with #23872 and #23885. Targeting the 10.10.0 release. This should allow users to log into Google via cy.origin but only if the navigation occurs from a domain that is NOT a subdomain of google (for instance, www.google.com -> accounts.google.com). Virtually every other case should be supported, but this is based on a small sample size.

[MounikaBodicherla]

@AtofStryker I upgraded to cypress 10.10.0 to use cy.origin() for google authentication (accounts.google.com). I am able to proceed with entering my email id and password. After that, the main application is not loading. Again, it is showing the page with the Google Login button. Could you please help me with the solution?

I used the below code:

cy.visit('Main application URL');
cy.findAllByText('google-saml').eq(1).click();
cy.origin('https://accounts.google.com/o/oauth2/auth/identifier', () => {
    //Google Authentication
    cy.get('input[type="email"]').type('email');
    Cypress.on('uncaught:exception', (err) => {
      if (err.message.includes('ResizeObserver')) {
        return false;
      }
    });
    cy.get('.VfPpkd-vQzf8d').eq(1).click(); //click on Next
    cy.wait(2000);
    cy.get('input[type="password"]').type('password');
    cy.get('.VfPpkd-vQzf8d').eq(1).click(); //click on Signin
  });
});

[AtofStryker]

@MounikaBodicherla would you be able to provide a small reproduction repository that we could clone and run to reproduce the issue?

[idanElitzur]

Recently I got CAPTCHA (questions about my email and my security questions) when trying to login by google connect with Cypress (v11.1.0). Any solution for this use case?

@AtofStryker

[AtofStryker]

@idanElitzur likely not since bot detection is outside of scope. Once our docs are updated for v12 I can point a reference here as to what our recommendations are. Have you tried programmatic login?

[idanElitzur]

Yes I did, didn't success for me, it's too complex maybe I missed something over there. do you maybe have a git repo with a full reference for this? v12 is too far 😞

[AtofStryker]

@idanElitzur are you trying to log into google in CI? It might not work due to secure apps issue logged in https://github.com/cypress-io/cypress/issues/24139. We won't be recommending social logins in CI as they might cause non deterministic test failures that are out of your control. Can you provide a reproduction that prompts the captcha?

[idanElitzur]

Sure, actually my implementations seems very similar to yours -

import * as loc from "./locators/google-login";
export const email = Cypress.env("gmail_user");
export const password = Cypress.env("gmail_password");
export let button = loc.submitButton;
export const userType = "google";
export const args = { loc, email, password };

export function googleLogin(
  button: string,
  appEndpoint: string,
  landingLoc: string
) {
  cy.session(
    userType,
    () => {
      cy.visit("/login");
      cy.get(button).should("be.visible").click();
      cy.intercept(Cypress.config("baseUrl") + "/**").as("redirect");
      cy.origin("accounts.google.com", { args }, ({ loc, email, password }) => {
        Cypress.on(
          "uncaught:exception",
          (err) => !err.message.includes("ResizeObserver loop limit exceeded")
        );
        cy.get(loc.username)
          .should("be.visible")
          .type(email)
          .should("contain.value", email);
        cy.get(loc.submitButton)
          .eq(3)
          .should("be.enabled")
          .click({ force: true });
        cy.get(loc.password)
          .should("be.visible", { timeout: 30000 })
          .type(password);
        cy.get(loc.submitButton)
          .eq(1)
          .should("be.enabled")
          .click({ force: true });
        cy.wait("@redirect", { timeout: 20000 });
      });
      cy.get(landingLoc).should("be.visible");
    },
    {
      validate() {
        cy.visit(appEndpoint);
      },
    }
  );
}

The captcha that return in this use case is more screens about validate my email address and answer to security questions. It's worked ok until the 2 weeks ago since you've fixed this problem in v10.10. so maybe i miss something or that is the same issue that you've experienced in your issue post. @AtofStryker

[AtofStryker]

Google did some under the hood changes around 2 weeks ago to more heavily bounce automated/bot traffic as we saw the same thing. Are you running this in CI? Also, would you be able to share a screenshot/video of what exactly you are seeing?

[idanElitzur]

Nope, I'm not execute it by the CI yet because is very flaky when executing this locally, almost the time is failed. I can send you a screenshot of the captcha questions but it will be in Hebrew and I guess you will not understand the context over there :D

[AtofStryker]

@idanElitzur that is OK! It is fairly likely that someone at Cypress can speak Hebrew 😄

[idanElitzur]

Hahaha 😆 Alright!

So it always happens when executing cypress headless by chrome and electron -->

Doesn't happen with firefox.

With opened runner + chrome or headed chrome it almost the times works ok and sometimes it's failed and returns security questions about what's your email and your phone number and etc.. but it's not so oftenly.

@AtofStryker

[AtofStryker]

@idanElitzur Interesting. Have you tried Microsoft Edge or Electron? Wonder if standalone Chromium would yield the same results

[AtofStryker]

This also looks like the older service login page. Interesting that this is getting served. Are you running headless or headful in that screenshot just to clarify?

[AtofStryker]

my colleagues were cool enough to introduce me to Google Lens. Pretty neat!

[idanElitzur]

Thanks for your answers :) Yes I did try with Electron and it happens as well and yes it happens only when executing cypress headless. Headed - works ok UI runner - works ok.

Also happens with Cypress 12.0.1

[Dnates-DoorLoop]

Was anyone able to overcome this issue?