Closed AtofStryker closed 2 years ago
The code for this is done in cypress-io/cypress#23872, but has yet to be released. We'll update this issue and reference the changelog when it's released.
Released in 10.10.0
.
This comment thread has been locked. If you are still experiencing this issue after upgrading to Cypress v10.10.0, please open a new issue.
What would you like?
If using
experimentalSessionAndOrigin
, I expect cookies to behave as if the AUT were top, in addition to attaching cookies appropriately given my request options.Why is this needed?
Currently, with the
experimentalSessionAndOrigin
flag enabled, the proxy server attempts to manage cross origin cookies via tough-cookie to apply cookies to requests that cannot be set in the browser. This is mainly due to the AUT and top origins possibly not matching after navigating and usingcy.origin
, attempting to apply/set cookies that would normally work if top and the AUT origins were the same.After the release of
10.3.0
, a few bug reports have been opened about the cookie behavior. Based on discovery, it looks like we may need to rework our strategy to managing cookies when theexperimentalSessionAndOrigin
flag is enabled, whether or not the user is actively usingcy.origin
.Currently with the fix introduced in #23438, cookies are applied optimistically, meaning that cookies that match the current
sameSiteContext
of the AUT are applied regardless of request options. One can think of this aswithCredentials
andcredentials
defaulting totrue
andinclude
forXmlHttpRequest
andfetch
respectively, which will cause cookies to potentially leak out of requests when they are not intended to be sent with the given request.Other
Since addressing these issues in one attempt is likely difficult, several e2e style tests were added in #23438 to showcase current behavior, with FIXME s introduced for incorrect behavior with commented out correct assertions. This should work as a testing base to verify our assertions once we attempt additional fixes on cookie management.
Moving forward, in order to get cookies to work as if they would in a natural browser state, the following needs to be done:
fetch
orXmlHttpRequest
) ?XmlHttpRequest
, waswithCredentials
specified in the request? The server will need to know this to appropriately attach cookies if cross-site / cross-origin requests are sent given the AUT origin. If no option is specified, we can assumeXmlHttpRequest
will send cookies to allsame-site
(notsame-origin
) requests and the server can attach cookies appropriately. This default behavior is different fromfetch
.fetch
, we need to know ifcredentials
were specified toomit
,same-origin
, orinclude
. The default issame-origin
, which as its name implies will only send requests to the same origin.same-site
requests need to specify theinclude
option. Knowing this information allows us to appropriately attach cookies in the server in addition to knowing the AUT origin.I created this little cookie behavior reproduction repository to showcase what the cookie behavior should look like as opposed to trying to replicate all of these scenarios manually, which is hard to remember and incredibly time consuming