Cookie::queue(...) does not take domain into account

[JonathanGawrych]

Laravel Version

11.24.0

PHP Version

8.2.19

Database Driver & Version

No response

Description

When setting two cookies using Cookie::queue(...), with the same name and path, but different domains, the two cookies are not sent to the client, but the latter one overwrites the prior. It works when calling response()->cookie(...) directly, just not when the cookie is queue.

It appears that Symphony's ResponseHeaderBag::setCookie() handles it by making one level of the cookie map, domain specific:
https://github.com/symfony/http-foundation/blob/3d7bbf071b25f802f7d55524d408bed414ea71e2/ResponseHeaderBag.php#L162

However, CookieJar doesn't, only caring about name and path:

framework/src/Illuminate/Cookie/CookieJar.php

Line 153 in 231091c

$this->queued[$cookie->getName()][$cookie->getPath()] = $cookie;

You may be asking why we are setting cookies on two different domains? The answer is that we are transitioning from using CORS to an API server, to instead have each subdomain have separate logins. During this transition we need to set cookies on both the subdomain and domain, and some of our cookies are queued inside services, rather created directly in the controller next to the response. Thanks.

Steps To Reproduce

Ensure the AddQueuedCookiesToResponse middleware is being used.

Add this code to any controller

// Logout request made on www.example.com
Cookie::queue(Cookie::forget('auth_cookie')); // lost
Cookie::queue(Cookie::forget('auth_cookie', domain: '.example.com')); // sent

View the response and see there is only one cookie set.

[github-actions]

Thank you for reporting this issue!

As Laravel is an open source project, we rely on the community to help us diagnose and fix issues as it is not possible to research and fix every issue reported to us via GitHub.

If possible, please make a pull request fixing the issue you have described, along with corresponding tests. All pull requests are promptly reviewed by the Laravel team.

Thank you!

[Sajid-al-islam]

created a PR but, but as queue and unqueue is part of the interface / contract it can't be changed on a patch release

[JonathanGawrych]

Yeah, I was working on it myself and found that.

Also I found that getPath() is not null, but domain might be null, and null is a valid value for domain. Thus we can't use null to mean unqueue on "any domain". I'm currently looking into defaulting to false, so you can pass in null explicitly.