Cypress concatenates cookies on redirects after POST when using `cy.request`.

[pehota]

Hi @brian-mann ,

In our company we're using cy.request for form submission in utility commands in order to speed tests up.
The forms are being submitted correctly but certain cookies are being concatenated at the redirects that happen after a successful POST.
Basically what we need is to create a new user before we run the tests and run the tests using him.
The first step is to login as admin and the second one is to create the user.
After submitting the login data the server sends a 302 status and redirects to the admin home page.
When this happens Cypress concatenates the session cookies (i.e. we see something like this when we inspect the request: session_dev =R0g0bVlqRVlnNXJkWHQwTzd1bUdERXNSemoyWDlybEVRcVFITVp4YkoyODhaV2F0Z3BBajdiQXhDUkUzTG4vVzBFOWNzdStLa3VMa0NiNDJoeWFzQjdUSUVuSXlrS1QyL1Q0ci9JS0ZsUGY3VGh2L0p6R2JmMGtpblBhQThuZjFZYWtMZHFTOGt6UFpFa2ZrT2pOUXBxMVRuU2J3NUxVY0tyYzR0U0xmOWZ3bTRZNjJZM0gvLzB1d3NQTlZ5ZXZoLS0wUVRTQktHOU53dWJYVHpJNFZOQkxBPT0%3D--4e98ae3094b98b2967dd2b96170ef1a7d1cb247f; session_dev =dFJnQWp3MkYzVGNpVFQ4MnFXcE1MNjRBbFR4UnB5WFFLU0tJT2tWUXFwMXpmMmdxbUUrUWdIWWJSY3oyYmQ4UjNEN3hFU0NEalQ5WnpBdHJCMk9sSHN3NFFFbC9Sc3JVc0FmWGVvRFRKUDJ3dG42L2dEZ3BVQXU0ZytNOS9UWHFUN2J5aWVlbWlOY0hUU0I1V21YOTRUNzl2K1UvMkE0YUU0QnluRzhtWVhzRXNBTnB2TWJaUE1ENkl0anN0c0NnVUFsU2VHNUFFVUpaeDdmMXZBR0NEWlY2Uk9qZ3RZbU1VNk8zVUcxL3B2dTdMc05Vb0M3eitMMS9ubUJtWkZrNjh4b2RNM001S0NiTms1Tnd5d0o1akJhNmVRU3lVZjJ0Tkk4SERpWklxajQ9LS1hRFIzbmJkRXlZSCtHRFpURlpDN1lBPT0%3D--e52508ff7d14831a0331b69c131fe43878e68e6e
The cookies become invalid and the server redirects to the login page again making it impossible to continue.

We're using a cookies whitelist in order to keep the session cookies.

Code

Cypress.Cookies.defaults({
  whitelist: [
    'session_dev',
    'session_prod',
  ],
});

Cypress.addParentCommand('submitForm', (options = {}) => {
  const requestOpts = Object.assign({
    method: 'get',
    url: '',
    followRedirect: true,
    form: true,
    body: {},
    headers: {},
  }, options);
  const { url } = requestOpts;

  // First get the auth_token and the form action by visiting the url
  // using a GET request
   cy
    .chain()
    .request(url)
    .its('body')
    .then((body) => {
      const $form = Cypress.$(body).find('form');
      const formAction = $form.attr('action') || url;
      const method = $form.attr('method') || $form.prop('method') || 'get';
      const authToken = $form.find('input[name="auth_token"]');
      const submitRequestOpts =
        Object.assign({ method: method.toUpperCase() }, requestOpts, {
          url: formAction,
          body: Object.assign(requestOpts.body, {
            auth_token: authToken.val(),
          }),
        });

      cy
        .chain()
        .request(submitRequestOpts);
    });
});

// Utility command for creating a new user
Cypress.addParentCommand('createUser', () => {
  cy
    .clearCookies()
    // login as admin
    .submitForm({
      url: '/login',
      body: {
         email: 'admin@ourcompany.com',
         password: 'password',
      },
    })
    // We're supposed to be logged in here and create a new user
    // Instead the GET request to `/users/new` gets redirected to the login page
    .submitForm({
      url: '/users/new',
      body: {
        email: 'test@test.com',
      },
    });
});

Basically the following happens:

• POST to login form
• Receive 302 to admin home page
• Request session cookies from previous requests are concatenated here rendering them invalid
• Redirect to login page because of invalid cookies

Hopefully I managed to explain the issue.

Thanks,
Dimitar Apostolov

[brian-mann]

Why are you whitelisting those cookie properties just wondering? Does removing them from the whitelist change anything? My guess would be no, but worth trying...

I reviewed your post and have a few more questions:

On the 302 redirect to admin home page. I'm assuming this is where the server does the initial Set-Cookie header to setup the session. I'm also assuming this works fine.

cy.request will automatically follow that redirect and perform a GET for the Location header. Can you verify that on that next request the session request cookie is set correctly and that the page does indeed load from your server?

If so, does the server set another Set-Cookie header there? I'm assuming thats where the problem is. We definitely have a bunch of logic around redirects and building up the cookie jar state, and my guess is there is something we didn't consider. This has been a bug in the past although we fixed it and added a ton of tests around this particular area. In the previous bug it was related to expiring Set-Cookie headers. My guess is that this bug is related to setting a Set-Cookie with a name that matches a previously held cookie.

Another thing that would be helpful is if you could do these 3 steps in your UI without Cypress and export a HAR of each request / response. You can do this in your Network tab in the Dev Tools. That way I could reproduce exactly what your server is sending and what the browser should be requesting.

Alternatively if you "clicked" on the cy.request command logs and took a screenshot of that requests/responses, I could likely figure it out from there too.

Another alternative is if you setup ngrok I could just hit your endpoints directly until I can see what the problem is.

[brian-mann]

Also what version are you on? I'm assuming the latest 0.18.3 at the moment.

[brian-mann]

Also wanted to comment that I think this line: const $form = Cypress.$(body).find('form'); is a very interesting use case.

I had not thought of pulling in the response body as a string and then querying it with jQuery. That is quite clever and would work well so long as your body returns the actual form and its not constructed with javascript (like a React component).

It looks like you're basically doing all of that to pull out the auth_token which is what I'm assuming is a CSRF token. An alternative to this (to make your testing life much easier) is just to return that token in a response header (which is useless to a regular browser) but would enable you to programmatically pull it out of a cy.request. Something like x-auth-token or x-csrf-token.

I also see that you are also utilizing the form's properties to construct the next cy.request, which is also clever, but alternatively you could also put those values as properties in a response header.

[pehota]

Thank you for the quick reply and the suggestions about improving the tests.
We need to preserve the cookies in order to log into our app just once at the beginning of the tests.
I tried not preserving the cookies but the result is still the same.
Your suggestions regarding using headers instead of parsing the response body require some backend changes so we'll stick with what we have currently for the time being.
I am seeing Whoops, the Cypress Chrome extension has disconnected when I try to run the tests at the ngrok url, but if you know how to overcome this issue I'll be more than happy to run ngrok for you.
Just let me know when it will be convenient for you to do that.

Thanks

[brian-mann]

I just need the ngrok url.

[brian-mann]

Okay I can reproduce on my end. Working on the fix now.

The problem only manifests itself on the subsequent 3xx redirect. Thats the only situation where the cookies are duplicated. If you were to turn off followRedirect and then make another cy.request it works.

Definitely a bug.

[brian-mann]

Related to #361 and #362.

[brian-mann]

Fixed in 0.18.4.