You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 using cy.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 the experimentalSessionAndOrigin flag is enabled, whether or not the user is actively using cy.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 as withCredentials and credentials defaulting to true and include for XmlHttpRequest and fetch 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:
Server side cookie jar likely needs to full knowledge of cookies defined through responses and directly in the browser so it can simulate the AUT as top correctly.
Requests in the proxy will need to know more information about the request in order to correctly mimc the browser and attach cookies correctly, such as:
What request method was used (fetch or XmlHttpRequest) ?
If XmlHttpRequest, was withCredentials 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 assume XmlHttpRequest will send cookies to all same-site (not same-origin) requests and the server can attach cookies appropriately. This default behavior is different from fetch.
If fetch, we need to know if credentials were specified to omit, same-origin, or include. The default is same-origin, which as its name implies will only send requests to the same origin. same-site requests need to specify the include 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
The text was updated successfully, but these errors were encountered:
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.
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
The text was updated successfully, but these errors were encountered: