ابحث في الدعم

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 has this problem
  • 13 views
  • آخر ردّ كتبه cor-el

more options

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)

more options

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/

more options

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.

more options

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.

more options

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.

more options

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.

more options

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.

more options

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