Cookies not being sent in redirect in 3.5.0

[jennifer-shehane]

Current behavior:

I'm not sure what the issue is, but our Single Sign On Recipe is failing here: https://dashboard.cypress.io/#/projects/6p53jw/runs/32571/failures

Desired behavior:

The Single Sign On should log in and reroute to dashboard page.

Steps to reproduce: (app code and test code)

1. Pull down https://github.com/cypress-io/cypress-example-recipes
2. Bump cypress dependency to 3.5.0
3. npm i in root directory
4. cd examples/logging-in__single-sign-on
5. npm start
6. in a new tab npm run cypress:open

Smallest amount of code to run:

it('can authenticate with cy.request', function () {
  cy.getCookie('cypress-session-cookie').should('not.exist')
  cy.request({
    method: 'POST',
    url: 'http://auth.corp.com:7075/login',
    qs: {
      redirectTo: 'http://localhost:7074/set_token',
    },
    form: true,
    body: {
      username: 'jane.lane',
      password: 'password123',
    },
  })
  .then((resp) => {
    expect(resp.status).to.eq(200)
    expect(resp.body).to.include('<h1>Welcome to the Dashboard!</h1>')
  })
})

Versions

3.5.0

[joshpzero]

Confirmed 3.5.0 also broke our SSO on multiple different auth types. Had to revert back to 3.4.1

[bahmutov]

Passing test in 3.4.1

Failing test in 3.5.0

Notice 4 requests instead of 3

[bahmutov]

The logs in 3.5.0 (I have added DEBUG=sso to this recipe)

GET /__cypress/tests?p=cypress/integration/logging-in-single-sign-on-spec.js-945 200 537.970 ms - -
  sso in /login +0ms
  sso checking username "jane.lane" and password "password123 +1ms
  sso username and password match, redirecting to "http://localhost:7074/set_token" +0ms
  sso redirecting to 'http://localhost:7074/set_token?id_token=abc123def456' +1ms
POST /login?redirectTo=http%3A%2F%2Flocalhost%3A7074%2Fset_token 302 17.207 ms - 75
  sso /set_token, query token is abc123def456 +5s
  sso redirecting to /dashboard +1ms
GET /set_token?id_token=abc123def456 302 3.774 ms - 32
  sso nope, redirecting to /unauthorized +14ms
GET /dashboard 302 0.537 ms - 35
  sso rendering unauthorized +10ms
GET /unauthorized 200 1.080 ms - 293

Around GET /set_token call

GET /set_token?id_token=abc123def456 302 4.440 ms - 32
  sso ensureLoggedIn middleware, headers [ 'Connection', 'keep-alive', 'user-agent', 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Cypress/3.5.0 Chrome/73.0.3683.121 Electron/5.0.10 Safari/537.36', 'accept', '*/*', 'accept-encoding', 'gzip, deflate', 'referer', 'http://localhost:7074/set_token?id_token=abc123def456', 'host', 'localhost:7074' ] session Session { cookie: { path: '/', _expires: null, originalMaxAge: null, httpOnly: true } } +16ms
  sso nope, redirecting to /unauthorized +3ms

[bahmutov]

The logs for 3.4.1, the same test "can authenticate with cy.request"

GET /__cypress/tests?p=cypress/integration/logging-in-single-sign-on-spec.js-057 200 955.854 ms - -
  sso in /login +0ms
  sso checking username "jane.lane" and password "password123 +2ms
  sso username and password match, redirecting to "http://localhost:7074/set_token" +0ms
  sso redirecting to 'http://localhost:7074/set_token?id_token=abc123def456' +1ms
POST /login?redirectTo=http%3A%2F%2Flocalhost%3A7074%2Fset_token 302 19.954 ms - 75
  sso /set_token, query token is abc123def456 +21s
  sso redirecting to /dashboard +0ms
GET /set_token?id_token=abc123def456 302 3.992 ms - 32
  sso session has id token +13ms
  sso rendering dashboard +0ms
GET /dashboard 200 1.891 ms - 155
  sso session has id token +82ms
  sso rendering dashboard +0ms
GET /dashboard 200 1.346 ms - 155

with more details around GET /set_token call

GET /set_token?id_token=abc123def456 302 4.511 ms - 32
  sso ensureLoggedIn middleware, headers [ 'Connection', 'keep-alive', 'user-agent', 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Cypress/3.4.1 Chrome/61.0.3163.100 Electron/2.0.18 Safari/537.36', 'accept', '*/*', 'accept-encoding', 'gzip, deflate', 'referer', 'http://localhost:7074/set_token?id_token=abc123def456', 'host', 'localhost:7074', 'cookie', 'cypress-session-cookie=s%3Aw87luiUkOIcbQPvug2Mx6EcI-xsw_HXg.S7%2F5tUA4EMVHDnDKmUChebs%2FJGQHmIXaapaRBKIrHEs' ] session Session { cookie: { path: '/', _expires: null, originalMaxAge: null, httpOnly: true }, id_token: 'abc123def456' } +13ms
  sso session has id token +2ms
  sso rendering dashboard +0ms

[bahmutov]

@flotwig seems like a cookie is not being sent in 3.5.0 after redirect

[skylock]

In 3.4.1

Cypress sets all cookies from request response headers set-cookie array

In 3.5.0

Cypress sets only first cookie element from request response headers set-cookie array

[PsySolix]

Can confirm: on our automated testing environment we had 30+ tests that succeeded. and used beforeEach to authenticate() with adfs and & before hook for Cypress.Cookies.preserveOnce('cookie_name');

*After updating to 3.5.0 -> they all fail *
Resetting to 3.4.1 -> all pass again

[jennifer-shehane]

There's a PR open to fix this here: #5455

[pete-om]

Heads up for anyone else encountering this, until a patch comes out I'm working around this issue by manually iterating through the set-cookies array, parsing all the key/values out, and calling cy.setCookie(name, value, etcetc) on each cookie

[PsySolix]

I can confirm, even with 3.6.0. The tests that pass in 3.4.1 (using cookies), all still fail in 3.6.0..

[cypress-bot]

Released in 3.6.0.

[jhappoldt]

Thanks @brian-mann. Should this issue be reopened until the issue is resolved?

[emijmker]

@brian-mann Same issue here so +1 on reopening. Tests with login fail on 3.6.0 and pass in 3.4.1. I see something about a release in 3.6.0 3 days ago, but when I download cypress again from https://docs.cypress.io/guides/getting-started/installing-cypress.html#Direct-download, I still get the 31st October version. Can this issue be reopened please? Thanks!

[flotwig]

Reopening since there are still some bugs with cookies + redirects. There is a PR open that should fix the issues people here are having: #5478

[cypress-bot]

The code for this is done in cypress-io/cypress#5478, but has yet to be released.
We'll update this issue and reference the changelog when it's released.

[cypress-bot]

Released in 3.6.1.

[emijmker]

@brian-mann I've tried the 3.6.1 version but still facing the same problem, so forced to stick to 3.4.1.

We do a BE call that generates a url with jwt token that redirects us to the final url we can visit and start testing FE from there.

https://hostname.com/somename/eyJhbetcetcSomeLongJwtToken
redirects to
https://hostname.com/pagetotest

In all versions after 3.4.1 something seems to happen to those jwt-urls so they're not valid and giving us a 504 when trying to visit them. The call to the BE in both cases gives us a 200 and produces a url.

The only difference I've been able to spot is in the response headers when selecting that call in the left Cypress menu and looking into dev tools:
In 3.4.1 no set-cookie
In 3.6.1 a set-cookie: Array(8)
My assumption is that those new (?) cookies (csrf, token) are messing up with the original ones.

Does this give any clues? Hope to hear back from you, many thanks!

[flotwig]

Hey @emijmker -

In Cypress 3.6.1 we fixed some cookie issues. Specifically, cookie within a redirect would not always be set on the correct domain.

Now, if you follow a redirect flow like this:

• www.example.com - sets foo = bar and redirects to auth.example.com
• auth.example.com - sets quuz = quux and redirects to www.example.com/cb
• www.example.com/cb - sets bing = baz and returns HTTP 200

You'll end up with these cookies:

• on www.example.com
  • foo = bar
  • quuz = quux
• on auth.example.com
  • bing = baz

Since this isn't working for you, do you think you could clearly describe the expected redirect flow + final cookies that you expect to be set, like I've done above? That will enable me to create a test case that I can use to figure out why it's not working as you expect.

[pete-om]

Still not fixed for me either.

Without a workaround, my authentication script still fails in 3.6.1. Cypress still appears to only process the first cookie in the set-cookie array. Everything works as expected in 3.4.1

The auth flow goes like this:

• cy.request (get) to /account/login
  • this sets token1 in a cookie
  • the body contains token2 as a hidden parameter in a form
• cy.request (post) to /account/login with form:true, and a body of token2, username, password
  • this results in a 302 redirect to /, with two cookies in set-cookie:
    • the first expires an sso cookie, which usually doesn't exist (but doesn't make a difference to this bug if it does exist)
    • the second sets the session auth token -- this part is failing in 3.5.0+. It exists in set-cookie, otherwise my workaround wouldn't work (manually doing a cy.setcookie on everything in the set-cookie bit), it's just not being set during the cy.request

So what we should be left with after all the above is two cookies: token1 and auth token. What I get as of 3.5.0+ is just token1 (from the original get request) and no auth token.

And we're not going outside our subdomain at any point so the cookies all have the same domain.

Note: if I cy.visit('/account/login'), type the username and password in and submit the form, the redirect sets all the cookies correctly and lets cypress log in, this method has never stopped working. It's only doing it via cy.request that's failing.

Hope this helps, let me know if there's anything else I can do :)

[djaromir]

I have similar issue authenticating using cy.request() too
Works fine in 3.4.1
In 3.6.1 it works in Electron but not in Chrome 78, desired cookies are not set after cy.request()

[flotwig]

@pete-om Thanks a ton for sharing these details! I will get to work on reproducing this and tracking down the issue. These details are awesome.

FYI, I moved your comment to an issue so we can track this more clearly, as this thread is getting messy. New issue: #5688 You might want to watch it to receive updates.

[codybarr]

I'm also still experiencing issues on 3.6.1... :/

[mbcopp]

Also experiencing issues on 3.6.1

Keep going back to 3.4.1

[hornta]

Should this be reopened? I can confirm it doesn't work in 3.6.1 but it works in 3.4.1

[tozes]

+1, also having issues on 3.6.1

[flotwig]

#5688 is being used to track another known cookie bug in 3.6.1, the specific bug from this issue has been fixed.