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        -        -  

[mattiasclaesson]

We are facing the same issue when running the tests in pipeline and currently we rely on the build published here by @AtofStryker. In docs it is specified that the pre-releases are only available for 60 days, and unfortunately the fix for this issue was not included in v13. What are the available options after those 60 days?

As stated above the fix did not help for me, so I created another issue:
#27528

[akotynski]

We have exactly the same problem. It blocks us from upgrading cypress (it worked in the previous versions). I managed to find out that it stopped working in version 10.10.0 (10.9.0 is the last working version)

[JKetelaar]

Any update on the change @AtofStryker? Would love to get this working on current 13.2.0 version

[AtofStryker]

@JKetelaar no updates as of yet

[JKetelaar]

@JKetelaar no updates as of yet@

Are you planning to publish the change soon? Currently it's blocking us to use Cypress, and the release provided by your commit is using an old version at this point (v12 instead of v13)

[madalinbucur152]

In our case, we switched back to v.10.9.0, as @akotynski states this was the last working version. @AtofStryker , do you think is possible to publish a new build with the same fix as here, on top of the latest version - 13.3 ? It will be really helpful to avoid using such an old version. Thank you!

[AtofStryker]

@JKetelaar no updates as of yet@

Are you planning to publish the change soon? Currently it's blocking us to use Cypress, and the release provided by your commit is using an old version at this point (v12 instead of v13)

@JKetelaar That's what makes this a bit challenging, as we really don't have a fix for this but a diagnostic binary that gives us a really good idea as to what the problem is.

In our case, we switched back to v.10.9.0, as @akotynski states this was the last working version. @AtofStryker , do you think is possible to publish a new build with the same fix as here, on top of the latest version - 13.3 ? It will be really helpful to avoid using such an old version. Thank you!

@madalinbucur152 I don't think this is a permanent solution by any means but yes I can take care of that. I will be out for some time and will return to triaging issues in 2024, but I will take care of that now and post the link to the binaries

The branch https://github.com/cypress-io/cypress/compare/same-origin-match-for-cookie-jar?expand=1 should now be based off of develop, which is 13.3.0. The updated binaries should be streaming in this commit: 8f84c80

[Gowthamijonna]

Hi,

We are facing issue while running cypress tests on application with custom domain. When the application URL has azurewebsites.net, we are not seeing any issue and able to login to the application.

When there is custom domain in the URL, after logging in we are getting blank screen and it redirects to the following URL
https://app.customdomain/#error=server_error&error_description=AADB2C90255%3a+The+claims+exchange+specified+in+technical+profile+%27SelfAsserted-LocalAccountSignin-Email-Migrate%27+did+not+complete+as+expected.+You+might+want+to+try+starting+your+session+over+from+the+beginning.

[madalinbucur152]

@AtofStryker We were relying on the previous build added here which expired these days. Can we have a new build with the same fix? Thank you!

[AtofStryker]

Hi @madalinbucur152. Sorry for the delayed response as I have been on leave for a few months. I kicked off a build based off develop that is running now on b67b0ee

[CristinaVeronica]

Hi @AtofStryker! Thanks for the fix! Would it be possible to have a permanent fix for this issue? It is quite unpleasant that once at 60 days (when pre-release build is not available anymore) to have our tests fail in the pipeline and be forced to downgrade to an older version - 10.9.0 - (which is the last working version) until a new pre-release build is available.
Do you think you can help us?
Thank you!

[AtofStryker]

Hi @CristinaVeronica. I completely understand as that does sound painful. Unfortunately we are unable prioritize a fix at this time. We are always welcome to taking contributions, but this fix likely means making changes to the cookie behavior around Cypress superdomain handling which could be a breaking change.

[jayathriZoftsolutions]

Hi we have exactly the same problem. It blocks us from upgrading new cypress versions I checked on version 13.6.5 any solution for this issue ?

[Ognengineer]

Hi @madalinbucur152. Sorry for the delayed response as I have been on leave for a few months. I kicked off a build based off develop that is running now on b67b0ee

Hi @AtofStryker can you please rebuild the patch as the old link retention policy kicked in.

[AtofStryker]

Hi @madalinbucur152. Sorry for the delayed response as I have been on leave for a few months. I kicked off a build based off develop that is running now on b67b0ee

Hi @AtofStryker can you please rebuild the patch as the old link retention policy kicked in.

its currently building on c7af4ad

[alexstpnkv]

Hi, I also met this issue and still need to use cypress 10.7.0. Are there any plans to unblock cypress updates?

[distancerunner]

One workaround: We added a second login option (Login via email link) to our page and I was able to implements tests. Fill out email, calling mails via imap, klick the email link and voila, I'm logged in. Its a bummer, that this is still an issue in cypress.

[Ognengineer]

Hi @madalinbucur152. Sorry for the delayed response as I have been on leave for a few months. I kicked off a build based off develop that is running now on b67b0ee

Hi @AtofStryker can you please rebuild the patch as the old link retention policy kicked in.

its currently building on c7af4ad

@AtofStryker me again with a request for a new build.

[AtofStryker]

Hi @madalinbucur152. Sorry for the delayed response as I have been on leave for a few months. I kicked off a build based off develop that is running now on b67b0ee

Hi @AtofStryker can you please rebuild the patch as the old link retention policy kicked in.

its currently building on c7af4ad

@AtofStryker me again with a request for a new build.

Ill get this taken care of today

[AtofStryker]

currently building on f4a46eb

[BartDeKrab]

@AtofStryker we also use this image, starting this afternoon its giving a 404, is it possible to make a new build?

[AtofStryker]

f4a46eb

@BartDeKrab just kicked off and is building on 1b69a11

[elkinjosetm]

Any update on this issue? We are also facing it with the same conditions described above, app in app.test.domain.xyz, B2C in auth.test.domain.xyz not able to authenticate when running the test

[AtofStryker]

Any update on this issue? We are also facing it with the same conditions described above, app in app.test.domain.xyz, B2C in auth.test.domain.xyz not able to authenticate when running the test

No updates as of now. We are at a fork in the road where a change of this type is likely a breaking change, which is currently unplanned. But fixing this issue almost goes hand in hand with #29590, which seems like is going to be unavoidable moving forward. The fog on the path forward is still somewhat cloudy.

[Ognengineer]

@AtofStryker Hello again, we are dependent on this, can you please make another build as the retention policy kicked in again?

[AtofStryker]

@AtofStryker Hello again, we are dependent on this, can you please make another build as the retention policy kicked in again?

@Ognengineer build is running on cd5ec48

[DmitrijK]

@AtofStryker Hey, can you please make another build? Thanks!

[AtofStryker]

@DmitrijK building on 0770d46. A more unrelated positive update: We are looking into #29590 as more of a generic application, which would likely include the cookie logic in this commit. The implementation details are still being worked out, but this is currently planned for Cypress 14