15

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).

Community
  • 1
  • 1
Sean
  • 1,698
  • 2
  • 16
  • 22

3 Answers3

11

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. The bug report was recently updated to note that this is fixed in Firefox 114.

muru
  • 4,723
  • 1
  • 34
  • 78
  • Well spotted, so this error may not be related to the issue I am seeing. Hmm – Sean Dec 29 '20 at 08:40
  • In my case the cookie wasn't deleted because Webpack dev server was fiddling with it. Firefox gave a confusing error message but it _does_ follow the spec. – sdgfsdh Sep 13 '21 at 10:38
3

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.

Jack Smith
  • 31
  • 1
1

I'm having a similar problem today with the same error message as the OP.

This happened in the past and my solution then was, rather than setting a time in the past, I set the value to nothing (as a failsafe) and also set 'expires' to 'time() + 1' (so a future time with the cookie expiring almost instantly).

    setcookie('cookiename','',[
        'expires' => time() + 1,
        'path' => '/',
        'domain' => $_SERVER['HTTP_HOST'],
        'secure' => true,
        'samesite' => 'strict'
        ]);

Unfortunately, this workaround seems to suddenly be failing today and that failure does seem to be unique to Firefox. (So, yup, perhaps an FF bug?)

Chrome and Vivaldi are still working fine with it. I didn't test on Safari nor Edge as yet.

Shaun of the Dead
  • 59
  • 1
  • 6