Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

This thread was closed and archived. Please ask a new question if you need help.

FF67 is deleting a session cookie too soon.

  • 7 பதிலளிப்புகள்
  • 1 இந்த பிரச்சனை உள்ளது
  • 16 views
  • Last reply by cor-el

A new problem has occurred since updating to FF 67.0.

My default configuration is to block all cookies. For those sites I wish to allow, I create exceptions to either Allow or Allow for Session.

On one of the sites I use I have an exception as: https://CompanyName.com Allow for Session (name changed to protect the innocent)

There are a number of subdomains used and so all subdomain cookies are allowed for the session.

As of FireFox 67, I could no longer log into the site. I found that it was stuck in a loop reloading the page.

If I allowed all cookies, then the login would work. Once logged in, I could block all cookies again and everything continued to work on the site. So it was only the process of logging in that was failing.

First thing I did was disable all cookie related add-ons. That didn't help. If I changed the setting for CompanyName.com to Allow, it worked. Next I tried setting CompanyName.com back to Allow for Session and tried each subdomain with the Allow. What I found was I need to change one specific subdomain to Allow, so now my exceptions list is like this: https://CompanyName.com Allow for Session https://login.CompanyName.com Allow

So it seems as though the necessary cookie for login.CompanyName.com was being removed early so the log in could not be completed. Once a log in was successful, I could look at the cookies and see them for this subdomain (as well as the others).

I can't see anything I did wrong, so I'm thinking there may be a bug somewhere in FF67.

A new problem has occurred since updating to FF 67.0. My default configuration is to block all cookies. For those sites I wish to allow, I create exceptions to either Allow or Allow for Session. On one of the sites I use I have an exception as: https://CompanyName.com Allow for Session (name changed to protect the innocent) There are a number of subdomains used and so all subdomain cookies are allowed for the session. As of FireFox 67, I could no longer log into the site. I found that it was stuck in a loop reloading the page. If I allowed all cookies, then the login would work. Once logged in, I could block all cookies again and everything continued to work on the site. So it was only the process of logging in that was failing. First thing I did was disable all cookie related add-ons. That didn't help. If I changed the setting for CompanyName.com to Allow, it worked. Next I tried setting CompanyName.com back to Allow for Session and tried each subdomain with the Allow. What I found was I need to change one specific subdomain to Allow, so now my exceptions list is like this: https://CompanyName.com Allow for Session https://login.CompanyName.com Allow So it seems as though the necessary cookie for login.CompanyName.com was being removed early so the log in could not be completed. Once a log in was successful, I could look at the cookies and see them for this subdomain (as well as the others). I can't see anything I did wrong, so I'm thinking there may be a bug somewhere in FF67.

All Replies (7)

Hmm, thank you for the details. If one hostname is a third party to the others, perhaps the more specific exception is needed to overcome a third party cookie block? I think this will need some more testing to understand how it changed.

If you want to engage with the developers, check whether there is a bug for this on Bugzilla, or file a new one: https://bugzilla.mozilla.org/

The cookie might not be removed, but simply not send with only an allow for session exception. An Allow exception might be needed to get full permission for third-party domains. Maybe you can check this in the Storage Inspector and in the Network Monitor to see what cookies are send.

There were no third party cookies involved. I should have stated in the original post that it worked fine when I allowed first party cookies only. Also, I had already looked with the developer tools mentioned by cor-el because my first instinct was that a third-party cookie was involved but that was not the case.

I just found another site that has a similar symptom... nextdoor.com.

I have an exception for https://nextdoor.com to Allow for Session.

When I try to log in as I've always been able to do before FF67, I get the following message appearing at the top of the window: There was an error establishing a session. Please try again. and it is still on the login page. Looking at the storage inspector, all the cookies are for nextdoor.com, nothing else.

If I allow first party cookies only, then the log in works.

For the nextdoor website the Network Monitor shows an XHR POST to https://flask.nextdoor.com So maybe in your case also check in the Network Monitor for a similar request to such a such a domain the compare the HTTP request headers to see what cookies are send in both cases. You can right-click the column header to select what column data to display.

Sorry, cor-el, but I think you've gone beyond me there. Yes, I see the XHR post to https://flash.nextdoor.com, but I don't know what I should be looking for or what the data is telling me.

I have confirmed that if I set https://nextdoor.com to Allow instead of Allow for session, it works. If I leave https://nextdoor.com as Allow for sesson and set https://flask.nextdoor.com to Allow, it still fails.

This behaviour is new to FF67. I'm not able to get into the guts of FF to try to figure this out. If I can be provided very detailed tests to do, I may be able to get further information. On the other hand, I'd assume a lot of people would have such problems and it should be easy to track down for those in the know. I don't see why it should just be me with this issue.

OP continued in a new thread, so locking this thread.