-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SetCookie::expire does not work: missing Domain part #23
Comments
The reason I did not make a patch right away is I wanted to trigger conversation on this. The main problem is, we have to include the domain information in the Set-Cookie header to get the "expiry happen" in the browser. I have not found any traces of automatic domain information retrieval in the response classes so we have to get the user to manually provide it to the SetCookie::expire method in a parameter or set it with ::withDomain(). So I see 2 solutions: Though I see the option A) more compact I do not like it very much since it kinda breaks the PSR-7 Response concept. On the other hand, option B) is not a real solution, rather a lame workaround correcting the fault of the PSR-7 design. What do you think? @vincentsys? If we can live with option A) I'll make the patch for that. |
Could you please elaborate on this:
adding a required parameter seems to be the way to go at first viewing. |
Would it be possible to share the code you are using to try and make this work? I haven't had a chance to dive into it too closely but it seems to me that the
Unless you are talking about |
@vincentsys I meant that according to PSR-7 the response message does not deal with the host that the subject message will be pushed out through. That is why there is no interface declaration for getHost or so. I think mixing in the host (that is a property of a Request type) here would go against this separation of 'topics' promoted by PSR-7. BUT there is no other way because we need the host information so I agree with you to ask for it via a method parameter. |
@djozsef Thanks for explaining!. Agreed! It looks like the |
For this fix, I'd recommend something like this. Happy to hear your thoughts on it: /**
* @param ResponseInterface $response
* @param string $cookieName
* @param string $domain
*
* @return ResponseInterface
*/
public static function expire(ResponseInterface $response, $cookieName, $domain = null)
{
$setCookie = SetCookie::createExpired($cookieName);
if ($domain) {
$setCookie = $setCookie->withDomain($domain);
}
return static::set($response, $setCookie);
} Since it is a static facade this will hopefully be somewhat BC as the Thoughts? |
I like your idea @simensen, it is exactly what was on my mind. Additionally I had a thought what if we check if the $domain parameter implements use Psr\Http\Message\RequestInterface;
...
/**
* @param ResponseInterface $response
* @param string $cookieName
* @param string|RequestInterface $domain Domain as string or a request object that
* implements RequestInterface
*
* @return ResponseInterface
*/
public static function expire(ResponseInterface $response, $cookieName, $domain = null)
{
$setCookie = SetCookie::createExpired($cookieName);
if ($domain instanceof RequestInterface) {
$setCookie = $setCookie->withDomain($domain->getHost());
} elseif ($domain) {
$setCookie = $setCookie->withDomain($domain);
}
return static::set($response, $setCookie);
} Am I complicating it too much? |
@simensen like it!
|
Would either of you like to create a PR and tests for this change? |
I agree @simensen, too much magic at the moment. I vote for your original code. Regarding the PR: this code is your baby but if it helps I can make a PR for that. |
@djozsef if you are up for it, please go ahead. it is more likely to get done if someone else does it at this point. :) i'm sure i'd get around to it eventually but if either of you need it right now, the best way to make that happen is to implement it so i can merge & tag. :) |
Bad news(?). I did further testing and it seems the problem is not the domain. Instead it is the withPath setting as described here #22. Adding the domain makes no difference for me. As soon as I remove the path, I am able to modify and expire the cookie. |
Ok, another test round. It seems if you set the cookie withDomain you need withDomain to modify/expire it, too! Setting it withPath also requires withPath modifying/expireing it! |
Sigh. Somehow when #4 came through I knew that this was going to be trouble but I couldn't quite put my finger on it. :-/ In order to be expired, cookies need to be defined exactly like they previously were with the exception of the value and the expiration time. So you cannot simply "delete a cookie" knowing just the name. It would be nice to get @franzliedke feedback on this as hopefully they've used it by now and have overcome some of these issues? At this point I'm tempted to suggest we try to find a way to rewrite this method entirely or drop it completely. |
Hmm, sorry about that. Bad to read when you get back from a holiday. ;) So if I understand this correctly, only the static methods ( So, to expire a cookie that was previously created, you would probably write something like the following: $expireCookie = $this->getCookieTheWayItWasCreated()->expire();
//... and now attach that to the response I can only suggest to release a new minor version that deprecates these pointless static methods (as people probably couldn't use them properly anyway), and then remove them completely with the next major release. Again, sorry for the mess - I don't think there's much more we can do here. |
I am also having an issue here. Even when trying to expire using @franzliedke suggestion, it doesn't work for me. The only way I can actually get a cookie to expire is to create it again without a value and set
|
@benjaminprojas Not sure I understand the exact problem here. Are you saying that, for my exception to work, |
@franzliedke I wasn't able to get your suggestion to work at all. The only way I could expire a cookie was to "create" a new one with the same name and with an expiration date in the past. |
@benjaminprojas Can you show us what exactly you tried then? It's hard to guess. ;) |
I solved it for me this way: #22 (comment) |
This is what we do at Flarum, and it works well: |
Any plans to fix it? |
I went ahead with my proposal to deprecate the misleading facade methods in #45. |
SetCookie::expire()
does not work for response cookies because browsers expect a "Domain" part in theSet-Cookie
header when expiring a cookie.I have tested it with Firefox 49.0.1 and Chrome 53.0.2785.143 and both behave in the same (standard?) way: the minimum requirement for expiring and flushing a cookie is to have the cookie name, the "Expires" part in the past AND also a "Domain" part in the
Set-Cookie
header.I could not really make a patch for this, since in response cookies no domain information is present. Any suggestion how to fix it in a canonical way?
The text was updated successfully, but these errors were encountered: