Tell HN: Unable to login to HN from Firefox, a Lovecraftian tale | Hacker News Reader

Tell HN: Unable to login to HN from Firefox, a Lovecraftian tale

andregarzia.com

144 pointssoapdog91 comments

Could it be that setting cookies for the domain was disallowed via the permissions dialog?

When I do that, I see behaviour like you are describing it: when I e.g. tried upvoting jedberg's comment with cookies disallowed, it actually worked. I was redirected to the login page and back to the discussion without staying logged in. After undoing the permission change, logging in and having a look at the exact comment, I saw that the vote actually went through. Posting a new comment showed the same behaviour.

You can find that permission on the "page info" dialog (shortcut Ctrl+I if that isn't localized?)?

Edit: the error message on the console would be different though. The described procedure leads to the message "Setting cookie ... has been denied because of a permission set by the user" (translated from German, so the actual message will be different). It looks like I was only describing the behaviour when cookies are unavailable and not the actual reason.

A helpful way to debug this is the "copy as Curl" feature in most browsers. That should give you the most true representation of what request is being sent to HN. Do it in private mode and non-private mode and then compare the differences.

The screenshot is probably out of date but here's how to use it https://everything.curl.dev/usingcurl/copyas#from-firefox

If you do this in chrome you'll get a long curl command that ends like this:

  --data-raw 'goto=item%3Fid%3D30166448&acct=ghiculescu&pw=(YOUR PW)' \
  --compressed

I found it most helpful to change that to

  --data-raw 'goto=item%3Fid%3D30166448&acct=ghiculescu&pw=(YOUR PW)' -v

So you can also see the response headers etc.

I see you tried private browsing and it works, so that would imply a bug in something that runs when not private browsing, so most likely a plugin that is blocking something.

Start doing a plugin bisection and see if you can find the offending plugin.

Been through that already. All add-ons disabled and the problem persisted.

Well, the idea still stands. Private->ok, not private->not ok. That's your telltale sign, go with the evidence, as a famous TV show says. Maybe you have something on your normal profile, I dunno what, but I like bashing Apple and since you say you're on MacOS, see what Apple does with that profile. Who knows, maybe you encounter a bug and you can get money out of it from Apple's bug hunting program. Good luck!

Have you tried uninstalling Firefox, deleting any residual appdata, and installing again? Have you tried installing the same version of FF Nightly and FF on another macOS computer?

Much less radical is just to use the command line options to create a new profile and see what happens. I have fixed obscure problems in firefox by blowing away the profile. 99% of what I need is stored in firefox sync so it's an easy process to delete an old profile and sync back up. Sounds like OP wants to get to the bottom of this though as a haX0r-ng project.

profiles need no command line anymore. Just use `about:profiles`, it's pretty cool!

Not yet. I'm trying to figure out what is going on before destroying everything.

I did try two different versions of Firefox on the same machine though (with different profiles).

Did you reuse existing profiles on both versions, or in either case did you start a completely fresh profile? If you haven't yet tested with a newly-created profile (which doesn't require deleting your existing profile), then you need to do so in order to triage whether the problem is with Firefox-by-default or Firefox-and-your-profile.

I'd try installing your version of FF Nightly on another macOS computer to rule out that possibility. Maybe it's not a config issue but something to do with Nightly which is affecting your other, release FF

Since it exists in both versions of FF, could you have anything installed which could be interfering with FF's communication with the rest of the internet? Are you on a network with a router which is able to modify your traffic (requires custom SSL certificate) (long shot)?

You can try a new profile? about:profiles

Maybe an addon made some FF config change which remains despite being disabled? Have you tried uninstalling all the add-ons as well?

When a problem is this specific to a single user, I begin to suspect actual bit-rot.

Probably worth checksumming the whole Firefox install against what it should be (or the poor man's checksum: uninstall it and reinstall it). If that fixes it, it might have been a one-time thing, or it might be the start of the end of that machine.

Ages ago, I had a machine administered by a company with a very robust binary check-summer. All of a sudden, one of the system libraries started failing to run... The check-summer would block any executable that tried to run with a hash that didn't match one on the allow-list. Took it to company IT, and they checked a couple things and said "No, this is a legit block... Your checksum doesn't match what the binary should be. Have you been having any problems with this machine?"

Wasn't until somebody asked that I realized the once-in-a-blue-moon kernel panics the machine would give were probably worth mentioning to someone. They concluded I probably had a disk controller with just enough badness to fail very, very occasionally... Usually the failure would manifest as a kernel panic, but I must have gotten unlucky and had it fail during a write operation without tripping a validation error. Replaced the machine; no further problems.

Could you attach a proxy (mitmproxy [1] for instance) and check the differences between HN requests with/without Private Mode ?

[1] https://mitmproxy.org/

When Mozilla started making big changes to tracking protection, somewhere around versions 86-90, I started noticing all sorts of broken credential management stuff, and I wonder if this is just another manifestation of that.

With strict ETP turned on, extensions like Cookie AutoDelete stopped working due to some new access restriction[0], and cookies that had been set while strict ETP was turned on—even when it was turned off again—became zombies that could only be deleted through about:preferences.

I’ve had to manually set `privacy.purge_trackers.enabled` to `false` to get it to stop automatically erasing (first-party!) login cookies several times per week. I do not understand what kind of heuristic is being used to decide something is a tracker, but it seems to be not good at it.

For a while, Firefox would also randomly prompt me for a master password after running for about 24 hours. This seemed to stop when I turned off strict ETP, but other people reporting the same problem said they didn’t even have strict ETP turned on to begin with, so who knows? It’s all just so random.

I still have situations today where I navigate (via the address bar or the browser history) to HN, or GitHub, or some other site where I have a valid login cookie, and Firefox just decides that it’s not going to send the cookie this time. If I reload the page, it decides now it will send the cookie. If I perform the exact same navigation that broke a moment ago, now it works fine.

I have no idea what changed, and everything that happens—just like the OP’s problem—is so weird and vague that I cannot even submit a decent bug report. At least this bug is consistent; most of my problems seem to be data races. I hope they are able to figure out what is going wrong and, ideally, that it leads to some fixes for whatever broken logic is causing so much trouble with credential management in general.

[0] https://github.com/Cookie-AutoDelete/Cookie-AutoDelete/issue...

Can confirm that I have experienced the same problem you've described (sometimes it just doesn't send the cookies upon initially navigating to a site, and after a refresh suddenly I'm logged in and everything is fine). It's so sporadic I don't know how to report it. At least it's not just me I guess :/

OP here: 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.

You mentioned clearing cookies from ycombinator.com. Did you also clear cookies from news.ycombinator.com?

yes, I did.

Have you tried diff'ing both profiles' about:config?

This is the epitome of technological blue balls. I really want to know what's going on. Have you tried making a completely new profile rather than modifying an existing one? Trying in private browsing mode? Making a new user in osx, installing Firefox for that user and trying to login?

I expect an update post when you finally get to the bottom of this!

I tried two different profiles, one for Nightly and another for Stable. None worked.

UPDATE: I can log in using private browsing... holy shit, what is going on!

Do you have any add-ons that are installed on both Firefox and Nightly, but that are not enabled in private browsing?

Can you log in to HN on a separate Firefox container?

https://support.mozilla.org/en-US/kb/containers

Containers do not share cookies, local storage, caches, or other persisted data.

I tried that, it didn't work. I love containers, and it was one of my attempts to solve it. I forgot to include that one in the post, I've tried so many things...

At this point, I'd create a new profile and try again. I know that you've already tried both Stable and Nightly, but there is a possibility that both of their profiles have been corrupted by some external factor. If the issue is not at the container level, then it's probably at the profile level.

https://support.mozilla.org/en-US/kb/profile-manager-create-...

Sounds like a corrupt profile in FF. I was coming to look for a comment that mentioned this.

It does. But damn, two corrupt profiles? One on each Firefox? What is the chance of that?!

Anyway, my last attempt will be to create a new profile. I was avoiding that because it feels like quitting. It feels like destroying everything and replanting the soil hoping for a better outcome even though you have no idea what happened before.

It's just a debugging step. Don't delete your existing profile. If you confirm that it's fine in a stock profile, then you can use various methods to see what's different and find the bug (eg. “what non-default settings overrides are set in my profile”).

Private browsing mode is always my first test for these weird issues. Usually it then boils down to an extension, cookies or cache. It sounds like you only cleared ycombinator related cookies. Maybe it’s worth clearing everything?

OP tried two different profiles on two different versions of Firefox, so it's unlikely to be cookie or cache related.

I also deleted cache and disabled add-ons, still not working.

The successful login with private browsing makes me hopeful though. Maybe I'll find a solution :-)

Try FF 95.x? FF 96 broke a lot of stuff.

Have you tried using a different profile?

My FF profile was corrupted once and a lot of sites stopped working mysteriously. Clearing cache didn’t help either. It has to be a new profile.

Make an entirely new profile, I bet it will work. I'm guessing both the existing profiles have something set that is breaking login. No idea what it can be, unless you explicitly blocked cookies from the domain. Not something that you can do accidentally though.

Yeah I've been down this frustrating route before. Somehow your profile has gotten corrupt. You'll probably never know why.

Has happened to me for Chrome and Firefox. Creating a new profile works. Or if you're feeling paranoid, remove any trace of it from the system and do a fresh install.

I stopped trying to figure it out when it happened. First step I take is "refresh firefox" https://support.mozilla.org/en-US/kb/refresh-firefox-reset-a...

If problem persists, new profile.

If problem continues, reinstall FF.

We used to call this "dataloss", "corruption".

Try looking at about:support to see if there are any third-party modules (antivirus etc. loaded). That has been a cause of problems like this in the past. More likely on Windows and I saw you're running macOS, but worth a shot.

It's worth a try, though Firefox has discontinued support for NPAPI plugins since version 52 (March 2017)⋮ https://support.mozilla.org/en-US/kb/npapi-plugins

The only plugins in the Plugins section of about:addons should be the OpenH264 plugin and the Widevine plugin (only if DRM is enabled). Both can be disabled there.

I experience the same issue, seemingly randomly, on firefox on Android. I log in, it redirects me to the home page, but I am not logged in. I retry over and over with the same result. The form is filled by my password manager, so I know it is right (I have manually typed in credentials as well, same result).

I just switch to chrome when it happens, and it seems to resolve itself at random. Last time it happened was a few months ago.

Just switched to FF Nightly on Android and logged into HN. Haven't reproduced the bug so far.

Debugging stuff like this is a real nightmare sometimes, but hey, maybe you’ll learn something cool in the process!

One thing I’d try would be to make a new profile - you can launch Firefox with the -P option to bring up the profile manager. I know it doesn’t work with either of your existing Stable or Nightly profiles, but maybe a clean profile will do the trick?

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

You were probably rate limited. I've gotten the "We're having trouble serving your request" thing many times when I accidentally open 20+ HN bookmarks.

HN limits POST requests to one every 2 seconds or so per IP address. I'm often getting this when upvoting/posting and then immediately performing an action in a different tab. I suspect this is a fairly recent change because I don't remember this being a problem a year ago or so.

Same here, when replying to someone in a thread and upvoting their comment in close succession.

Sometimes just vote and immediate click on 'reply' makes it happen, and only one of those is a POST.

What's the upvote action? Wasn't it changed to a POST after the "this upvotes itself" entry?

> Like Ged in Earthsea, this is my own personal devil. I need to get rid of it

The book ends with Ged accepting that the devil/shadow is part of him, I’m hoping this story has a happier ending!

Yes, but it was the only story I remembered on the spot that had a very personal devil that challenged only the main character :-)

I too am hoping this has a happier ending. All wisdom here points towards making a new profile, which is something I'm avoiding, but if there is no other choice I might try it later.

This sounds exactly like the issue I've been having with my company's instance of Nexus Repository 3 for the past several months. It's a SPA, so I can "log in" and the UI reflects being logged in, but all of the API calls to the backend return a 403. However, this doesn't happen if I use private mode.

I've tried logging off and on HN, and logon is fine (Linux, version 91).

May be you can try:

1. Check the clock on your machine. Make sure it's not running at a time beyond 2038.

2. Check the disk space on your machine, especially where the profile is stored. Out of space error can be causing other errors.

3. Check the file system read/write permission on the profile folder.

4. Make sure there's not another instance of Firefox running. In fact, reboot just to be sure.

5. Try older versions of Firefox, with the portable versions. There's a command line argument to use an existing profile or a new one. Try those. This would narrow the problem down to whether it's caused by your machine or versions of Firefox. https://mozilla-firefox-portable.en.uptodown.com/windows/ver...

Good luck.

Maybe try running Wireshark and check that the request from FF to HN is sending the cookie?

If the server is fine, the only cause I can imagine is that the request after login does not report the cookie as set. Wireshark should help confirm whether the request is ok.

Then run strace on Firefox and check that the request written out by FF is ok. If that's fine too, then Mac OS must be fudging the request somewhere between when FF writes to the socket and when it actually leaves your machine?

No need for a proxy to check it. HN is very old-school, it is very easy to see the raw requests and stuff. Everything looks as it should be, it just doesn't work.

I'm inclined to believe there is something funky going on with both my profiles. The odds of that happening is very low, but I don't see other options.

I was scared to try this, but I logged out and tried logging in again just now (using Firefox). It worked OK. I'm on Firefox 96.0 on Linux, FWIW.

That used to be a thing with Firefox profile corruption so they had a tool to copy all your data to a new profile and start there. I think that was pre 2014 ish?

Considering it worked with new profile it is very likely that is what happened here. I am not sure if the profile migration is still there though.

If you are on Windows and your Firefox profile got borked, try ShadowExporer to restore the profile version that still worked. Also check if File History is on and has a copy of your profile (those two are separate features). Then check if you have image backup enabled.

An annoying "feature" of firefox is that if you (even temporarily) run low on storage it will go into a mode where localstorage (and indexdb?) stop working. This makes a lot of sites break for seemingly no reason. You have to restart Firefox to fix it.

Fortunately, HN is not such an abomination that relies on all these “features” when static html, a tiny bit of CSS, and a light sprinkle of JS to gracefully enhance the experience would suffice.

The one thing I noticed is that the updates you posted are at least 3 hours in the future from me (EST). Where are you located? Maybe it has something to do with you being in a certain timezone?

How many bytes is the cookie? Large cookies silently fail to be stored. Do the cookie contents change significantly between private and non private?

Posting from a newly installed Firefox 96.0.3 on macOS 11.6. (I've never had Firefox on this OS image before.)

So I'd guess this is a user-specific issue?

It's not like HN is a JavaScript-heavy application with lots of polyfills either! If you can't log in to HN, how do you log in anywhere?

I can login to other sites without any hiccup. Also, I can log in to HN from other browsers. I have no idea what is going on. :-(

Can you try Lynx/Brave/Waterfox as well? I'd personally be curious to diff the HN cookie stored in each browser and see if there's a difference unique to FF.

I'd also be curious to diff the HTTP requests sent from each browser, particularly FF vs FF forks.

Does setting the cookie using the javascript console (on ycombinator.com) trigger the same expired message? Could be a good angle if it does.

Chuckled at

" Then I deleted all the ai_user cookies because if I’m having a bad time, so should Google Analytics. "

Have you tried looking at the browser privacy settings and adjusting them? Not sure if you’re on strict or standard.

I'm on standard. That was one of the first things I checked even though I didn't write that step on the post.

Time to attach a debugger?

This might be related to a corrupt profile.

It looks like it, but it is happening on two separate profiles. Both my Nightly profile and my Firefox stable version profile. Unless both profiles are corrupt, which would be odd.

Maybe they are both corrupt due to the near-2038 cookie? It would be weird, but … bugs can be weird.

Then other people on FF and FF Nightly should be having the same issue

What happens if you use Tor Browser?

Are you running any extensions?

OT but what theme is that?

It is called Graffiti - Balanced.

This is why I use Chrome, never had even the slightest problem with it on any site.

Except for Google using it to track every single website and URL you visit.

And preventing you from using a real ad blocker.

And running background processes on your computer that tell Google what other programs you have installed, the visible SSIDs from your WiFi chipset, etc.

Not even the slightest problem.

Reply on news.ycombinator.com