I'm losing my mind here - I'm looking into an issue where some signout functionality in an application I have isn't working because the authentication cookie is not being cleared. The thing is that our "signout" endpoint does include the appropriate set-cookie
header in the response - here's what I get looking at the raw response in Firefox:
set-cookie: Auth.myapp=; domain=app.mydomain.com; expires=Thu, 26-Nov-2020 13:19:20 GMT; path=/; secure; HttpOnly
Firefox is reporting this error in the console:
Cookie “Auth.myapp” has been rejected because it is already expired
This is kind of confusing, not only have I successfully used set-cookie
with a past-date in expires
before, it's even codified in RFC6265 as the accepted way to request a client remove a cookie:
Finally, to remove a cookie, the server returns a Set-Cookie header with an expiration date in the past. The server will be successful in removing the cookie only if the Path and the Domain attribute in the Set-Cookie header match the values used when the cookie was created.
So I need to set an expires
date in the past to clear the cookie ... but doing so causes the browser to reject it? Does anyone know what's going on here?
To be clear I have checked that the cookie name, path, secure
and SameSite
match (update: I suspected that because I hadn't explicitly specified a SameSite this might be the cause, but after making sure the cookie is both set and cleared with SameSite=None
it is still not working).
Type about:preferences#privacy<enter> in the address bar. The button next to History, select Use Custom Settings. Turn off Always Use Private Browsing Mode Turn on Remember My Browsing And Download History At the bottom of the page, turn on Clear History When Firefox Closes.
However, you can direct the user's browser to delete the cookie by setting the cookie's expiration date to a past date. The next time a user makes a request to a page within the domain or path that set the cookie, the browser will determine that the cookie has expired and remove it.
As far as I can tell, the message is harmless - the cookies are indeed deleted based on my testing. And Googling the message leads to this changeset, which indicates that the deletion does happen, just with additional logging.
// If the new cookie has expired -- i.e. the intent was simply to delete
// the old cookie -- then we're done.
if (aCookie->Expiry() <= currentTime) {
COOKIE_LOGFAILURE(SET_COOKIE, aHostURI, aCookieHeader,
"previously stored cookie was deleted");
+ CookieLogging::LogMessageToConsole(
+ aCRC, aHostURI, nsIScriptError::warningFlag,
+ CONSOLE_REJECTION_CATEGORY, "CookieRejectedExpired"_ns,
+ AutoTArray<nsString, 1>{
+ NS_ConvertUTF8toUTF16(aCookie->Name()),
+ });
NotifyChanged(oldCookie, u"deleted", oldCookieIsSession);
return;
The message seems unnecessary however, and there is a bug report about it.
This occurs when using a null , false, or empty string in the cookie value. It is only flagged as a warning in Firefox. Other browsers do not show this warning.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With