emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#59546: closed (qutebrowser and icecat stuck in infinite browser chec


From: GNU bug Tracking System
Subject: bug#59546: closed (qutebrowser and icecat stuck in infinite browser checks (cloudflare) on applicable sites)
Date: Thu, 15 Dec 2022 04:33:02 +0000

Your message dated Wed, 14 Dec 2022 23:32:36 -0500
with message-id <87h6xxcmmz.fsf@gmail.com>
and subject line Re: bug#59546: qutebrowser and icecat stuck in infinite 
browser checks (cloudflare) on applicable sites
has caused the debbugs.gnu.org bug report #59546,
regarding qutebrowser and icecat stuck in infinite browser checks (cloudflare) 
on applicable sites
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
59546: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59546
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: qutebrowser and icecat stuck in infinite browser checks (cloudflare) on applicable sites Date: Thu, 24 Nov 2022 10:11:03 -0600
I have hit this issue before, but not in a while. I don't know for sure
when the issue came back as it only matters for the initial login or
visit of the offending sites, so if you manage to get past you'll be
good until your cookie expires or gets deleted somehow. I got logged out
of many sites in qutebrowser recently and was made aware of the issue
being back. I also tested in icecat where some sites I still had a
cookie, but I managed to find one with a browser check and it indeed
never completes (can leave it open hours or even more than a day).

Some sites to test with include:
https://www.livechart.me/ (must click login button, main page works)
https://www.gitlab.com/ (again must click log in to start the check)

Since this is happening in both icecat and qutebrowser with different
user agents and everything, I suspect a guix-related issue. I found that
at least one other person on IRC was also experiencing the infinite
browser checks. I use a few sites daily that are now unusable on my Guix
System machine due to these browser checks, so a fix would be very much
appreciated if anyone could figure this out.

guix version:
guix (GNU Guix) eb5e650e09dd096c066278918456f3e989f7b9d9
running Guix System as my distro
Issue first noticed (again) under a week ago, but could be older.
In the past I fixed it by spoofing a firefox user agent the same way in
both browsers, but it seemed like it was not working to do that anymore.
Currently I have both browsers set to default UAs again, also not
working.
There is also a relevant closed issue on qutebrowser's github:
https://github.com/qutebrowser/qutebrowser/issues/7208



--- End Message ---
--- Begin Message --- Subject: Re: bug#59546: qutebrowser and icecat stuck in infinite browser checks (cloudflare) on applicable sites Date: Wed, 14 Dec 2022 23:32:36 -0500 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Hello,

"bdju" <bdju@tilde.team> writes:

> I have hit this issue before, but not in a while. I don't know for sure
> when the issue came back as it only matters for the initial login or
> visit of the offending sites, so if you manage to get past you'll be
> good until your cookie expires or gets deleted somehow. I got logged out
> of many sites in qutebrowser recently and was made aware of the issue
> being back. I also tested in icecat where some sites I still had a
> cookie, but I managed to find one with a browser check and it indeed
> never completes (can leave it open hours or even more than a day).

> Some sites to test with include:
> https://www.livechart.me/ (must click login button, main page works)
> https://www.gitlab.com/ (again must click log in to start the check)
>
> Since this is happening in both icecat and qutebrowser with different
> user agents and everything, I suspect a guix-related issue. I found that
> at least one other person on IRC was also experiencing the infinite
> browser checks. I use a few sites daily that are now unusable on my Guix
> System machine due to these browser checks, so a fix would be very much
> appreciated if anyone could figure this out.

I've had that too with Gitlab when using Icecat.  Sadly, it has nothing
to do with Guix but with how Cloudfare and the website identifies
browsers.

For example, I had found out that by using a Windows Firefox 83 user
agent, I was able to login into Gitlab (using this plugin:
https://gitlab.com/ntninja/user-agent-switcher).  I reported the issue
to Gitlab, and they could apparently fixed it on their side (not yet
deployed) [0]

[0]  https://gitlab.com/gitlab-org/gitlab/-/issues/345328

I think other sites or CloudFare must be similarly faulty, or require
fingerprinting which is guarded against out-of-the-box in IceCat.

Closing, as I doubt Guix has something to do with it.  If you find
something to the contrary, let us know!

-- 
Thanks,
Maxim


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]