Azure AD B2C bad request when redirecting / using cy.origin()

[mmonteiroc]

Current behavior

We are trying to do a login with cypress, and we tried to use the "cy.origin" command. In local this worked well, as the domain of the login was a complete different one. Once we launched this in the pipeline, started complaining cypress that the "super domain" was the same one ( same error as this issue ).

As cypress identifies the login domain as the same domain, we assumed that then we could use the cypress commands directly in that page, so we did the following condition so that the code would be executed with origin or without depending of the environment:

 const loginFunction = ({ username, password, emailInput, passwordInput, nextButton }) => {
    cy.get(emailInput, { timeout: 5000 }).should('be.visible').type(username, { log: false });
    cy.get(passwordInput).type(password, { log: false });
    cy.get(nextButton).click();
  };

  // When localhost, we need the "origin command"
  if (Cypress.config('baseUrl').includes('localhost')) {
    cy.origin(
      loginOrigin,
      {
        args: {
          username: usernameForLogin,
          password: passwordForLogin,
          emailInput: LoginPage.emailInput,
          passwordInput: LoginPage.passwordInput,
          nextButton: LoginPage.nextButton
        }
      },
      loginFunction
    );
  } else {
    // When deployed, we don't need the "origin command"
    loginFunction({
      username: usernameForLogin,
      password: passwordForLogin,
      emailInput: LoginPage.emailInput,
      passwordInput: LoginPage.passwordInput,
      nextButton: LoginPage.nextButton
    });
  }

Problem comes that when we are doing the login in the CI ( not using the cy.origin ), one response of loading a page returns a 400 ( usually returns a 302 that page - With cy.origin or by normal usage of the login )

Same code executed in localhost, and using the cy.origin works just perfectly

Desired behavior

That the code works the same with or without origin

Test code to reproduce

Provided in the description

Cypress Version

12.5.1

Node version

18.13.0

Operating System

Windows 10 19042.2486

Debug Logs

No response

Other

SSO for the login used is Azure AD B2C

Frontend application is Angular with @azure/msal-angular

[mmonteiroc]

[UPDATE] - This has nothing to do with query params. We found that the params are added by the SSO provider.

Nevertheless, there is still an issue here. When doing the login manually or with cy.origin works properly, and the page load returns a 302 to our app ( redirect with a login status )

But when doing it without the cy.origin but with cypress, the page returns a 400.

Maybe the proxy of cypress is not proxying well the request

[sebastiandenis]

@mmonteiroc we have encountered a similar issue. We also use Azure AD B2C.

Everything works fine for localhost and cy.origin wrapped around B2C SSO page. But when we open the app on an actual domain for example app.domain.xyz and we have our B2C login page on login.domain.xyz, we can't use cy.origin (the same super domain) and we get the AADB2C90255 B2C error (_The claims exchange specified in technical profile '{0}' did not complete as expected. You might want to try starting your session over from the beginning).

I have tried almost everything, still without success :/

[flotwig]

Hey @mmonteiroc and @sebastiandenis - could you please try updating to Cypress 12.7.0? We included some bugfixes related to session, origin, and cookies that may resolve your issues: https://docs.cypress.io/guides/references/changelog#12-7-0

[sebastiandenis]

@flotwig @mmonteiroc I've tried with the 12.7.0 version, the same result.

But today we've made a little test. We've run the same app on a different super domain, so we could use cy.origin(), and it worked. It looks like the whole magic for Azure AD B2C to work fine is somewhere in the cy.origin() method.

Scenario 1: app.domain.xyz -> login.domain.xyz (can't use cy.origin(), the same super domain - B2C doesn't work). Scenario 2: app.domain2.xyz -> login.domain.xyz (can use cy.orgin(), B2C works fine).

Any ideas on how to force Cypress to let me use cy.origin between different subdomains but the same super domain?

[mmonteiroc]

Same behaviour in our side @flotwig @sebastiandenis

We face the issue only when using same "root domain" ( which is our case so we need to keep it like so ).

When we are outside of the same domain ( localhost for instance ), and we have to use cy.origin works perfectly fine ! So same question as @sebastiandenis, can we force the usage of cy.origin ?? Or maybe tell cypress how to consider a different origin?

/ping @mjhenkes as I see that @flotwig removed it self and added you :)

[mjhenkes]

You guys could try two things:

1. enable experimentalSkipDomainInjection https://docs.cypress.io/guides/references/experiments#Experimental-Skip-Domain-Injection This will allow you use cy.origin on sub domains in the same root domain, though you may see some side effects since all sub domains will be treated as cross origin

2. You could try flexing your test logic depending on if you're localhost or not, i know this isn't ideal but in CI you may not need cy.origin at all since you are in the same super domain.

Overall i think we need to address this ourselves to provide a more user friendly experience but that could take some time.

[mmonteiroc]

Will try that feature. But if you see my example code, i have the code already adapted for CI, and the issue is that fails when not using the cy.origin() @mjhenkes

[sebastiandenis]

@mjhenkes I've tried with the skip domain injection option, but I can't make it work, Cypress fails with the error message:

cy.origin() requires the first argument to be a different origin than top. You passed app.domain.xyz to the origin command, while top is at https://app.domain.xyz

Either the intended page was not visited prior to running the cy.origin block or the cy.origin block may not be needed at all.

I've tried with different configurations (including visiting domain app.domain.xyz before using cy.origin) but the same result.

For now, as we have a dedicated environment for E2E tests, we want to test the solution that our app is on a different port than the B2C login page: app.domain.xyz:12345 -> login.domain.xyz - as we've observed it may work (Cypress doesn't complain about the same super domain). We don't want to have a different domain for this E2E environment, but if it is necessary, probably we will do it.

[mjhenkes]

@mmonteiroc @sebastiandenis, could you guys give me a brief overview of your auth flow for both local and in ci? I've been trying to figure it out from the comments above but i'm getting lost somewhere.

I don't need any specifics, just the general flow. ie

1. user visits www.site.com
2. user is server side redirected to auth.site.com (is it a server side redirect or a browser redirect?)
3. users enters username and password then logs in
4. user is redirected back to www.site.com

Does your site user auth tokens or cookies?

[mmonteiroc]

So on our side the flow is the following:

• User tries to access our angular SPA.
• MSAL Library detects that user is not loged in ( access token overdated / not existing )
• MSAL redirects to the login page of login ( login managed by our SSO Azure AD B2C )
• User puts email / password
• Credentials are validated
• Once validated, azure does a redirection ( 302 ) to our application, in which provides us the token through the URL

The problem on our side, is that when we dont use the cy.origin ( as cypress understands it as a same domain ), this supposed redirection of 302, converts to a 400 Bad request. With that data, I understand that cypress has some strange issue inside the http proxy that makes this happen 🤷‍♂️

If you need, I am happy to run the tests with some logs enabled and provide you some data to help debug ? Let me know please.

[mmonteiroc]

@mjhenkes FYI, this flow mentioned above is the same one in local / ci .

The only difference is that in local, the redirections happen between localhost and login.whatever.domain.com And in CI, the redirection is between else.whatever.domain.com

[sebastiandenis]

@mjhenkes similar on our side. We have an Angular app that uses angular-auth-oidc-client (oauth code flow) + Azure AD B2C.

We have our app available on: app.domain.xyz Our B2C login page is sitting on: login.domain.xyz

Everything works fine when we run Cypress and it tests the app running on localhost (and using cy.origin):

1. we go to our app on localhost
2. we aren't authorized so the app redirects us to the B2C login page (login.domain.xyz)
3. we have 2 steps form on the B2C side (the first page is where you type your login only, then there is a request to B2C and if everything is fine with the login, there is the second page, where we put the password.
4. if everything is ok, there is a redirect to localhost from the login.domain.xyz with the token.

When we run tests with the app that is available on app.domain.xyz and we remove cy.origin (because of the same super domain Cypress error):

1. we go to app.domain.xyz
2. the app redirects to the B2C login page: login.domain.xyz
3. on the B2C login page we can input the login (the first step in the B2C login form)
4. request goes to the B2C and it redirects us to our app (app.domain.xyz) with the error message: AADB2C90255 B2C error (_The claims exchange specified in technical profile '{0}' did not complete as expected).

I believe that it's a similar case to @mmonteiroc but we have a little different B2C configuration. When we wrap the actions on the B2C login page with cy.origin (inside cy.session) everything works fine. But when we remove cy.origin, B2C fails.

[mjhenkes]

@sebastiandenis, @mmonteiroc , When you tried experimentalSkipDomainInjection were you visiting the auth domain inside of the cy.origin block our outside? When dealing with auto redirects it's best to visit inside the cy.origin block.

I put together an example below to describe why. Hope it helps.

const login = (username, password) => {
  // without experimentalSkipDomainInjection login.domain.xyz and app.domain.xyz are same super origin and cy.origin will error. 
  cy.origin(
    loginOrigin,
    {
      args: {
        username,
        password,
      }
  }, ({username, password}) => {
    cy.visit('/') // visiting inside the cy.origin block prevents top from being set. This visit redirects to login.domain.xyz. Top would have been set to login.domain.xyz.
    cy.get('username', { timeout: 5000 }).should('be.visible').type(username, { log: false });
    cy.get('password').type(password, { log: false });
    cy.get('submit').click(); // redirects back to originating origin (localhost or app.domain.xyz)
    cy.wait(100) // may or may not be needed, wait a touch on the site to ensure tokens are setup if not using cookies.
  })
}

it ('authenticates', () => {
  // base url is set, causing top to be set to either localhost or app.domain.xyz
  login(username, password)

  // You're now back at '/' in localhost or app.domain.xyz
})

[mmonteiroc]

Hi ! @mjhenkes I had finally time to try it with the experimentalSkipDomainInjection and still does not work for us. Also I followed the comment you mentioned about visiting the page only inside the origin, and even like this, our error still persists. We get the 400 after the request of the login.

The config is the following one experimentalSkipDomainInjection: ['*login-staging.iotlab.connect.bobst.com'], Where the domain that the tests are executed is ra-develop.iotlab.connect.bobst.com

With the property you provided, is true that we dont have to differentiate between using or not the cy.origin. But apparently this was not the solution to the problem.

The code used is the following:

  // Cypress "controling" the origin of the login
  const loginOrigin = Cypress.env('appConfig').activeDirectoryB2CCustomDomainName;

  const loginFunction = ({ username, password, emailInput, passwordInput, nextButton }) => {
    cy.visit(Cypress.config('baseUrl'), { failOnStatusCode: false });

    cy.get(emailInput, { timeout: 5000 }).should('be.visible').type(username, { log: false });
    cy.get(passwordInput).type(password, { log: false });
    cy.get(nextButton).click();
  };

  cy.origin(
    loginOrigin,
    {
      args: {
        username: usernameForLogin,
        password: passwordForLogin,
        emailInput: LoginPage.emailInput,
        passwordInput: LoginPage.passwordInput,
        nextButton: LoginPage.nextButton
      }
    },
    loginFunction
  );

[mmonteiroc]

@mjhenkes please let me know if i can provide u any logs that might help you investigate this :)

[mjhenkes]

@mmonteiroc, could you compare the cookies/tokens sent for a successful auth outside of cypress against an unsuccessful auth inside of cypress? Anything different about the requests could help.

Maybe we're loosing cookies or mangling them?

[mmonteiroc]

@mjhenkes I will try to investigate this. I may take 1 day to come back to you, but will do it as soon as possible :)

[pietervdheijden]

I've the exact same setup and problem as @sebastiandenis: my Angular app is hosted on app.domain.com, my B2C login page is hosted on login.domain.com and MSAL returns error AADB2C90255. Also, upgrading Cypress to 12.7.0 or enabling experimentalSkipDomainInjection does not work...

[mmonteiroc]

@mjhenkes @AtofStryker I just have done what @mjhenkes asked me, and for what I see, the requests are almost identical between both domains ( deployed / localhost ) The only difference, is the cookie itself, as is encoded depending on the timing, etc... but the same amount of cookies are sent, same payload, etc

[ghost]

Hi all, I have the same issue. I've done the suggested test and obtained the same results as @mmonteiroc. There is no difference in the request. I ran the same failed request(HTTP 400) via curl and got a successful response.

[AtofStryker]

@mmonteiroc interesting. I wonder if there is something additional going on in the proxy layer that might tell a different story. When you compared the request, did you do so in devtools? Would you be able to send any of the logs if you set DEBUG=cypress-verbose:proxy:http? I am wondering if we have a different value stored in the server side cookie jar with origin that might change the cookie value in the request as well.

It seems like the next steps here, besides sending the logs, might be to get a minimal reproduction up and running. I don't have a B2C account, but might be able to set one up easily. Any idea how we can create one similar to your set up without a ton of config? If we can do that, and parity hosting, I would think this would be fairly reproducible.

[mmonteiroc]

@AtofStryker

Im sorry, but seems I cannot manage to get these logs in the output of the terminal. I ran the following commands: set DEBUG=cypress-verbose:proxy:http To enable the logs

And cypress run --reporter cypress-multi-reporters --reporter-options configFile=cypress.reporter.json --spec .\cypress\tests\administration\apim-subscriptions-smoke.spec.ts

To run the test, and the only logs I see are these ones:

> cypress run --reporter cypress-multi-reporters --reporter-options configFile=cypress.reporter.json --spec .\cypress\tests\administration\apim-subscriptions-smoke.spec.ts


[15612:0324/161733.911:ERROR:node_bindings.cc(279)] Most NODE_OPTIONs are not supported in packaged apps. See documentation for more details.
Fetching config
Fetching feature flags
The tests will run with the following feature flags:  [ 'WORKFLOW' ]

====================================================================================================

  (Run Starting)

  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ Cypress:        12.8.1                                                                         │
  │ Browser:        Electron 106 (headless)                                                        │
  │ Node Version:   v18.13.0 (C:\Program Files\nodejs\node.exe)                                    │
  │ Specs:          1 found (apim-subscriptions-smoke.spec.ts)                                     │
  │ Searched:       C:\DEV\FrontendService\Client\cypress\tests\administration\apim-subscriptions- │
  │                 smoke.spec.ts                                                                  │
  │ Experiments:    experimentalMemoryManagement=true,experimentalSkipDomainInjection=*login-stag… │
  └────────────────────────────────────────────────────────────────────────────────────────────────┘


────────────────────────────────────────────────────────────────────────────────────────────────────

  Running:  apim-subscriptions-smoke.spec.ts                                                (1 of 1)

  (Results)

  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ Tests:        1                                                                                │
  │ Passing:      0                                                                                │
  │ Failing:      1                                                                                │
  │ Pending:      0                                                                                │
  │ Skipped:      0                                                                                │
  │ Screenshots:  1                                                                                │
  │ Video:        true                                                                             │
  │ Duration:     1 minute, 8 seconds                                                              │
  │ Spec Ran:     apim-subscriptions-smoke.spec.ts                                                 │
  └────────────────────────────────────────────────────────────────────────────────────────────────┘


  (Screenshots)

  -  C:\DEV\FrontendService\Client\cypress\output\screenshots\should display the apim     (1280x720)
      subscriptions page properly\should display the apim subscriptions page properly
      before all hook.png


====================================================================================================

  (Run Finished)


       Spec                                              Tests  Passing  Failing  Pending  Skipped  
  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ ×  apim-subscriptions-smoke.spec.ts         01:08        1        -        1        -        - │
  └────────────────────────────────────────────────────────────────────────────────────────────────┘
    ×  1 of 1 failed (100%)                     01:08        1        -        1        -        -  

[AtofStryker]

@mmonteiroc are you running in powershell?

[sebastiandenis]

I've just finished an Azure CI pipeline for Cypress runs using Azure AD B2C. Because our app is on the same domain as B2C login page (but on a different subdomain), we had to prepare a separate environment for Cypress and connect with a different domain than the B2C login page (so we can use cy.origin). Everything works fine with cy.origin! The main reason for the separate environment is that we build the app a little differently (we don't include Service Worker). Another solution (if your app is on the same domain as the B2C login page) could be to set a different port for the app - it could work, I think. But for us, it was easier to connect a different domain than change the port. I hope the Cypress team will find the cause of that issue and solve it soon 🤞

[mmonteiroc]

@mmonteiroc are you running in powershell?

@AtofStryker / @emilyrohrbough Yes I am running locally / CI in powershell to run cypress.

( Sorry for the late reply, but has been a messy week )

[emilyrohrbough]

@mmonteiroc I have never used Azure AD B2C before, however doing some research to gain some context on the issue you might be experience, it sounds like the Bad Request / AADB2C90255 errors that have been reported on this thread is due to incorrect payload. Like @AtofStryker suggested, proving debug logs would help determine what is being sent and compare that to what is expected.

Another option might be to check the Azure AD B2C logs to see if there are additional details in the payload and responses as to why the request coming from a Cypress test is being reject. It may be a bit more obvious to identify the discrepancies from the tool granting access to the application.

[emilyrohrbough]

Also super left-field question - but is this happening in all browsers? Is this by chance running fine in Firefox?

[Xan0C]

We have the same problem in our use case: Using cy.origin works when the login domain is under a different origin e.g. test.testlogin.com and application is under e.g. test.myapp.com On our prod system we have login.myapp.com and myapp.com and therefore can not use cy.origin. We did a workaround to simply repeat the failing bad request which does use the corrected cookie on the second try:

cy.intercept('GET', `${getLoginUrl()}/*/B2C_1A_signup_signin_oauth_jds/api/CombinedSigninAndSignup/confirmed?**`).as(
    'loginRequest'
  );
  loginAzure(username, password);
  // Workaround, since it can happen that cypress does not set the correct cookies on the initial login request
  cy.wait('@loginRequest').then((resp) => {
    if (resp.response?.statusCode === 400) {
      cy.request({
        method: 'GET',
        url: resp.request.url,
        headers: resp.request.headers,
      }).then((authResp) => {
        // reload the page with the updated session data
        expect(authResp.status).to.eq(200);
        cy.visit('');
      });
    }
  });

Without cy.origin the set-cookie header does not get applied correctly between 2 consecutive requests. I think this issue is related #26040 #25841

After some digging yesterday evening I've found that the response-middleware behaves differently if the login domain uses a different origin.

https://github.com/cypress-io/cypress/blob/9517def6b7a95a975b5eadc9454ff0541c8eca0e/packages/proxy/lib/http/response-middleware.ts#L432-L438

Removing those lines and therefore saving the cookie in the CookieJar solves the issue for our use case. I am not really sure why exactly this helps so at this point i am just guessing, it looks like "though-cookie" is responsible to sync the cookies between requests? And when using the same origin the call to https://github.com/cypress-io/cypress/blob/9517def6b7a95a975b5eadc9454ff0541c8eca0e/packages/proxy/lib/http/response-middleware.ts#L456 does not happen.

https://github.com/cypress-io/cypress/blob/9517def6b7a95a975b5eadc9454ff0541c8eca0e/packages/proxy/lib/http/util/cookies.ts#L240 https://github.com/cypress-io/cypress/blob/9517def6b7a95a975b5eadc9454ff0541c8eca0e/packages/server/lib/util/cookies.ts#L122

[AtofStryker]

@Xan0C This is really helpful. I have a feeling the cookie isn't getting set in the browser in your case since its cross-origin / same-site, and the cookie jar logic doesn't think it needs to be simulated since it is same-site, when in fact it does need to be simulated.

I wonder if we need to actually store the full origin string and then check to see if there is a sub domain in the simulation code so we still simulate cookies correctly on cross-origin / same-site requests from the AUT if the url of the AUT is an origin match.

could you try the changes in this branch and see if they also work for you? https://github.com/cypress-io/cypress/compare/same-origin-match-for-cookie-jar?expand=1

[Xan0C]

@AtofStryker Works like a charm =). Also checked it with a testcase where we test the complete password reset flow, which previously was failing and now works with the build from the branch.