Unable to login to HN from Firefox, a lovecraftian tale.

Posted Tuesday, February 1st, 2022 

web

I love an epic tale of debugging. You know, those fantastic stories in which an ingenious person goes on a quest to solve a problem and end up in triumph and glory. Sherlock-Holmes-of-debugging kind of stories. Well, this is not one of those tales. This is a very personal problem, not an epic quest. Apparently it is only affecting me. This is also a Lovecraftian tale because I’m slowly getting mad because of it.

It all begun when I logged out of Hacker News and all of a sudden couldn’t log back in. It is a very strange behaviour, the login form redirects back to the homepage as if nothing happened. My password is not wrong. I thought that maybe it is a HN bug, give it some days for them to notice and fix it.

Many days passed. I noticed that I could still post and upvote because those actions would redirect me to the login page. After filling my info there and submitting the form, whatever action I was attempting to do would go through, but I would still not be logged into the webapp. I tried using some other browsers such as Safari and Vivaldi. In those browsers, I could log in normally. I started living a kind of double life, using Firefox for most of my browsing and Safari for when I wanted to interact with HN.

That got boring really fast. I still kept at it because I’m lazy. I have better things to do. That bug, laughing in the distance, haunted my dreams.

I got fed up with it and started investigating. It boiled down to the user cookie being rejected because of its expiry date being already in the past.

Well, that looks easy to fix, right? I checked the Network tab on Firefox DevTools and saw that the expiry date for that cookie was in 2038. Time is flying during the pandemic, but it is not flying that fast. 2038 is still in the future. Why is Firefox saying it is not? I posted a Ask HN post asking if someone experienced a similar problem. A clever user pointed me to Year 2038 problem, and I thought that was it.

Today I decided to message the HN mods about it. This led to various messages being exchanged with Daniel who has been extremelly helpful trying to debug this. We both though that the problem might be related to the expiration date being too close to the 2038 cut-off date. He made a temporary change to set the expiration date on the cookie to 2032 instead, and I tried again.

At that point, Daniel confirmed that they could log in and out of HN from Firefox on his side. Other Firefox users are silent as well. Had this been happening to other users, I bet they’d be screaming. The problem looks like a personal hellscape. Like Ged in Earthsea, this is my own personal devil. I need to get rid of it.

Clearing cookies

My first step has been trying to inspect whatever cookies I had set for the .ycombinator.com domain. I cleared them all on Firefox settings interface. It didn’t work.

I mostly browse using Firefox Nightly because I’m one of those people who think your browser needs to have bugs to keep your web experience fresh and enjoyable. Maybe it was something wrong with Nightly. Launched Firefox stable, which I haven’t launched in ages, and attempted to log into HN. No cookie for me. It still didn’t work.

Be aware that Firefox Nightly and Firefox stable use different profiles. The user data from one version is separate from the other. I can log in to HN from all other browsers in my machine except Firefox. It doesn’t matter what profile I use and what Firefox version I use.

I disabled all the cool add-ons that makes web browsing a pleasant experience—such as uBlock Origin and friends—cleared cookies and tried again. It still didn’t work.

I came like a wrecking ball...

In my frustration, I decided to do what you should not do with your browser: fiddle with internal files. Firefox on macOS stores it’s data in the Application Support folder. MacOS hides this folder for a reason. The reason being Apple doesn’t want to answer support calls when you break things up.

Once inside the folder for my Nightly profile, I opened the cookies.sqlite file and kicked some buckets.

After searching about this problem, I’ve seen some old reports that Firefox was somehow failing to clear old cookies, and that it happened once you had more than 3000 cookies set. I had 3055 cookies on that profile. First step was deleting any cookie for the Y Combinator host. Then I deleted all the ai_user cookies because if I’m having a bad time, so should Google Analytics. That reduced my cookie count below 2000.

I STILL CAN’T LOGIN TO HN.

Maybe it is the cookie syntax...

Inspecting the raw response from HN server, I noticed that the date is using dashes instead of spaces:

Set-Cookie: user=sadboi; Expires=Thu, 01-Jan-2032 00:00:00 GMT; HttpOnly; SameSite=Lax; Secure

Maybe that was it. Isn’t the format supposed to be with spaces instead? The info on MDN WebDocs about set-cookies is really lax on the date format. It looks quite flexible.

Experimentation is the mother of learning! I decided to quickly build a little Web Server and try to set my own cookies using dashes in the date and see if I could replicate the bug in a different site. The quickest way for me to build most of my toys is to use LiveCode—a modern-day HyperCard—and just create a simple stack.

The code is quite minimal, it just replies with some text and attempts to set two cookies: one with dashes in the expiry date and another without.

on startServer
   put empty into field "debug"
   httpdStart "NewRequest", 12345, "My Server"
   launch url ("http://localhost:" & it)
end startServer

on NewRequest pSocketID, pRequest
   put arraytojson(pRequest,,true) into field "debug"

   put "Set-Cookie: userWithDashes=kenobi; Expires=Thu, 01-Jan-2032 00:00:00 GMT; HttpOnly; SameSite=Lax; Secure" & crlf into tHeaders
   put "Set-Cookie: userNoDashes=kenobi; Expires=Thu, 01 Jan 2032 00:00:00 GMT; HttpOnly; SameSite=Lax; Secure" & crlf after tHeaders

   httpdResponse pSocketID, 200, "Hi There, General Kenobi!", tHeaders
end NewRequest

Guess what? Dates with dashes work. I have no problem setting those cookies. They work fine. That is not the problem.

I STILL CAN’T LOGIN TO HN.

A clueless user goes inside Application Support

Went back to the profile folder. You know you’re desperate when you start using mdfind to look for clues.

$ mdfind -onlyin . ycombinator

I could see that ycombinator was present in some files and folder inside my profile. There was a cache folder for it full of empty files, and also a security related file which I think is related to that Strict-Transport-Security header. I nuked that cache folder.

I STILL CAN’T LOGIN TO HN.

Final words

If you’re frustrated because there is no happy ending here, imagine how I feel. I have no trick left to try. I don’t have this problem with any other site, and I don’t have this problem with other browsers. It is a spawn of hell that is born out of the conjunction of my Firefox installation and HN. I deleted all occurrences of ycombinator from the profile. No cookies, no cache, nothing. And it still doesn’t work.

I think I’ve tried to fix this enough for today. I wanted to post about this problem once I solved it, but it is quite clear that I can’t solve it. Maybe some reader can, maybe you can help guide me out of this maze.

Updates

I’ll post updates as I figure stuff out.

1st of February 2022 at 18:21: If I use private browsing, there is no bug and I can login without problem. The problem still there if I use my normal profile.

1st of February 2022 at 18:37: I think that some devs at HN are investigating it. Now, HN is giving me an error in Safari when I try to open the site. I was logged in on Safari. I can still open the site if I’m not logged in.

That problem lasted just some minutes. I’m back logged in in Safari.

1st of February 2022 at 20:03: I created a new profile in about:profiles. I can login into HN from that profile. The bug is in the profile then, I just need to figure if it is fixable without nuking the profile.