cypress: Unable to login via Azure AD with cy.origin as cookies are blocked

Current behavior

Hi,

I’ve been using Puppeteer to login using Azure AD as Cypress was not able to load the page to perform the login

I have now upgraded to cypress 12 and I am able to load the screen and type in the user name, the problem is microsoft azure AD is saying cookies are disabled on the chrome browser that Cypress launched

It means that I can’t complete the login as it breaks after the username is entered

image

Desired behavior

I would like to use Cypress to login via Azure AD, I assume the only issue here is the browser that is launched by Cypress has cookies disabled, so I need to know how to enable them if possible for Cypress

Test code to reproduce

    cy.origin(`https://login.microsoftonline.com`, () => {
        cy.visit("/");
        const username = Cypress.env('username');
        const password = Cypress.env('password');

        cy.get('[name="loginfmt"]').should("be.visible").type(`${username}{enter}`);
        cy.get('[name="passwd"]').should("be.visible").type(`${password}{enter}`);
        cy.get('[type="submit"]').click();
    });

Cypress Version

12.1.0

Node version

v16.19.0

Operating System

Windows 10 Enterprise

Debug Logs

No response

Other

No response

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 1
  • Comments: 36 (17 by maintainers)

Most upvoted comments

Can this be related to :#25605

If so, I would also like to test the patch

@reshadatavid It is possible. I should be able to investigate that issue today

@guzmanoj I am going to work on getting a binary you can try that you can install through npm. I will update when it’s available. What OS are you on again?

@guzmanoj thank you for pointing me in the right direction! So I spent some time digging today and I think there is a bug in our cookie patch:

So to check if cookies are enabled, Microsoft sets a cookie called CkTst that is set to a value and then checks if that cookie is truthy/available.

Immediately after checking if that cookie exists (which it does), the cookie is then removed. But the way this cookie is removed is by setting the value to "" and setting the expiry time to a value in the past from now (in this case, a date from 1980). So the cookie is set, and then immediately removed, which has the delete effect.

We are not checking the expiry time of the cookie before setting it, which means the cookie is being set in the jar when it isn’t supposed to be:

To test this theory, I added a naive patch to the cookie patch to remove a cookie in the jar if its past expiry (if exists) and do not set it. This seems to fix the issue with the only know way I have to test it, which is putting in a wrong password.

Before adding the naive patch

https://user-images.githubusercontent.com/3980464/214143070-a42db19c-1115-4100-9ae0-0e5b2d343eaa.mp4

After adding the naive patch

https://user-images.githubusercontent.com/3980464/214143091-8f1cb22b-8bf1-4476-bb54-0cc2e2655e78.mp4

I’m going to route this issue over to the e2e team as I think we can come up with a fix for this.

@guzmanoj no updates yet, but hoping to investigate this hopefully this week