Can't Open the signin page. It keeps showing: Checking your browser before accessing gitlab.com

@saii626 I find it strange that you have to disable it.

mine has the standard profile, with fingerprinting being blocked, and there isn’t a problem logging into gitlab.com - have you tried a private window in Firefox? Have you also tried in Brave/Chrome and do you have the same problem normally or incognito mode? Have you also tried disabling any plugins you have that might be affecting your ability to login?

I tried in private window in firefox and disabled my plugins. Still nothing. I have Enhanced Tracking Protection at Standard too. It works in chrome. Only way it worked for me on firefox is by disabling fingerprinting.

Anyway, I have found a difference between my “personal gitlab account” and my “work for money” firefox profiles. Both are running the same Firefox version 93, and quite similar configuration.

Looking at the console, one of the cloudflare cookies has wrong time set when the browser tries to set it: https://megous.com/dl/tmp/9e8e10b5e5e57cb9.png This does not happen in my personal firefox profile.

But when I clear all cookies and local storage, my work profile keeps getting some https://megous.com/dl/tmp/de84fa2394b9b999.png experimental_subject_id cookie set and my personal does not https://megous.com/dl/tmp/dbcbf61395e86643.png

So it’s either cloudflare or gitlab doing some A/B testing. Probably trying to see how many people leave their platform when they block them from accessing their web UI for work.

Do you want a direct answer to your A/B tests here on the forum? Because I can provide one. LOL :slight_smile:

Maybe check some “ No A/B tests on our customers, please” checkbox in your cloudflare config.

I don’t think that has anything to do with it, since I just browsed gitlab.com on my private profile and I have the experimental_subject_id cookie. If that was the case, then mine would fail as well.

You may be part of a different experiment perhaps?

Anyway whatever variant of their experimental code cloudflare is serving to me, is broken.

As I said, that has nothing to do with it, if it did then it would affect everyone. Have you tried running a VPN to change your location, and visit the site from a different IP than your current internet connection? There are plenty of free VPN services you can try to check/test.

Perhaps also try a clean Firefox profile that hasn’t had it’s default configuration changed, as we can then see if it’s related to your profile/settings or not.

I’ve tried with a default Firefox profile. Works as expected.
I then logged out, enabled privacy.resistFingerprinting and tried again. I got stuck at the “Checking Browser” page.
I switch on my VPN and tried again, no dice.

I fail to see how the issue isn’t the “privacy.resistFingerprinting” being enabled. This seems to be a recent development as well as I’ve used LibreWolf to use GitLab in the past which has “privacy.resistFingerprinting” enabled by default and it hasn’t caused an issue until recently.

I’ve tried with a default LibreWolf config, same issue.
I turn of privacy.resistFingerprinting, works fine.

Follow up question, what is GitLab checking from the browser? Is it checking in the user has dark mode enabled by any chance? I’m pretty sure “privacy.resistFingerprinting” prevents that information being sent.

Is there a solution that doesn’t involve me changing my privacy settings ?

4 Likes

I never had resistFingerprinting enabled in that profile.

I already stated that it gitlab works on the same computer in my personal firefox profile (that one has much tighter privacy settings) or in chrome. So it’s not an IP address. It’s some cloudflare issue.

Anyway, it’s not resistfingerprinting. It’s 1735193 - privacy.resistFingerprinting makes Cloudflare DDoS protection loop forever

dom.enable_resource_timing = false

Changing that to true, makes cloudflare shut up and load the page.

Weird, I had dom.enable_resource_timing set to true already, still no dice. Changing it to false made no difference either of course.