GNU bug report logs - #45179
qutebrowser/IceCat stuck at Cloudflare "Checking your browser before accessing..."

Previous Next

Package: guix;

Reported by: "bdju" <bdju <at> tilde.team>

Date: Fri, 11 Dec 2020 14:45:02 UTC

Severity: normal

Done: Michael Rohleder <mike <at> rohleder.de>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45179 in the body.
You can then email your comments to 45179 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#45179; Package guix. (Fri, 11 Dec 2020 14:45:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to "bdju" <bdju <at> tilde.team>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Fri, 11 Dec 2020 14:45:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "bdju" <bdju <at> tilde.team>
To: <bug-guix <at> gnu.org>
Subject: qutebrowser stuck on browser checks forever
Date: Fri, 11 Dec 2020 08:41:09 -0600
guix (GNU Guix) 91e35e32a4938e0e37499c64fa8ed3e7cf51dce3
some example sites with browser checks:
https://gitlab.com/users/sign_in
http://livechart.me/

I already contacted the people in the qutebrowser IRC. The bug persists
when I launch with no config (`qutebrowser --temp-basedir'), and they
could not reproduce the issue on the same version of qutebrowser I'm
using. I suspect it may be an issue with the guix version.




Changed bug title to 'qutebrowser stuck at Cloudflare 'browser checks'' from 'qutebrowser stuck on browser checks forever' Request was from Tobias Geerinckx-Rice <me <at> tobias.gr> to control <at> debbugs.gnu.org. (Fri, 11 Dec 2020 19:25:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#45179; Package guix. (Tue, 22 Dec 2020 16:35:01 GMT) Full text and rfc822 format available.

Message #10 received at 45179 <at> debbugs.gnu.org (full text, mbox):

From: Michael Rohleder <mike <at> rohleder.de>
To: "bdju" <bdju <at> tilde.team>
Cc: 45179 <at> debbugs.gnu.org
Subject: Re: bug#45179: qutebrowser stuck at Cloudflare 'browser checks'
Date: Tue, 22 Dec 2020 17:34:41 +0100
[Message part 1 (text/plain, inline)]
Hello bdju,

"bdju" <bdju <at> tilde.team> writes:
> guix (GNU Guix) 91e35e32a4938e0e37499c64fa8ed3e7cf51dce3
> some example sites with browser checks:
> https://gitlab.com/users/sign_in
> http://livechart.me/
>
> I already contacted the people in the qutebrowser IRC. The bug persists
> when I launch with no config (`qutebrowser --temp-basedir'), and they
> could not reproduce the issue on the same version of qutebrowser I'm
> using. I suspect it may be an issue with the guix version.
>

A workaround is setting the "User Agent" string to something CF likes, e.g. like this:
qutebrowser --temp-basedir --set content.headers.user_agent 'Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0' https://gitlab.com/users/sign_in

Maybe the reason why the (very helpful) #qutebrowser folks can't
reproduce this, is because they use another qt version (qutebrowser uses
qtwebengine) and perhaps this sets user agent to a string that CF has
whitelisted.

I don't think there is much we could do here (besides updating qt and
mbakke has that in the pipeline, afaik).

-- 
COFFEE.EXE Missing - Insert Cup and Press Any Key
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#45179; Package guix. (Sat, 23 Jan 2021 05:00:02 GMT) Full text and rfc822 format available.

Message #13 received at 45179 <at> debbugs.gnu.org (full text, mbox):

From: Ben Sturmfels <ben <at> sturm.com.au>
To: Michael Rohleder <mike <at> rohleder.de>
Cc: 45179 <at> debbugs.gnu.org, bdju <bdju <at> tilde.team>
Subject: Re: bug#45179: qutebrowser stuck at Cloudflare 'browser checks'
Date: Sat, 23 Jan 2021 15:58:48 +1100
On Tue, 22 Dec 2020, Michael Rohleder wrote:

> Hello bdju,
>
> "bdju" <bdju <at> tilde.team> writes:
>> guix (GNU Guix) 91e35e32a4938e0e37499c64fa8ed3e7cf51dce3
>> some example sites with browser checks:
>> https://gitlab.com/users/sign_in
>> http://livechart.me/
>
> A workaround is setting the "User Agent" string to something CF likes, e.g. like this:
> qutebrowser --temp-basedir --set content.headers.user_agent 'Mozilla/5.0
> (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0'
> https://gitlab.com/users/sign_in
>
> Maybe the reason why the (very helpful) #qutebrowser folks can't
> reproduce this, is because they use another qt version (qutebrowser uses
> qtwebengine) and perhaps this sets user agent to a string that CF has
> whitelisted.
>
> I don't think there is much we could do here (besides updating qt and
> mbakke has that in the pipeline, afaik).

I'm also having similar issues accessing gitlab.com with IceCat.
Installing the User Agent Switcher and setting to "Linux / Firefox 82"
fixed this for me.

For context I also tried starting IceCat up in safe mode and switching
tracking protection back to "standard", but no good. The issue appears
to be that Cloudflare are essentially blocking niche user agents.

Regards,
Ben




Changed bug title to 'qutebrowser/IceCat stuck at Cloudflare "Checking your browser before accessing..."' from 'qutebrowser stuck at Cloudflare 'browser checks'' Request was from Ben Sturmfels <ben <at> sturm.com.au> to control <at> debbugs.gnu.org. (Sat, 23 Jan 2021 05:02:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#45179; Package guix. (Sun, 24 Jan 2021 00:08:01 GMT) Full text and rfc822 format available.

Message #18 received at 45179 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Ben Sturmfels <ben <at> sturm.com.au>, Michael Rohleder <mike <at> rohleder.de>
Cc: 45179 <at> debbugs.gnu.org
Subject: Re: bug#45179: qutebrowser stuck at Cloudflare 'browser checks'
Date: Sat, 23 Jan 2021 19:05:54 -0500
ben--- via Bug reports for GNU Guix <bug-guix <at> gnu.org> writes:

> I'm also having similar issues accessing gitlab.com with IceCat.
> Installing the User Agent Switcher and setting to "Linux / Firefox 82"
> fixed this for me.
>
> For context I also tried starting IceCat up in safe mode and switching
> tracking protection back to "standard", but no good. The issue appears
> to be that Cloudflare are essentially blocking niche user agents.

The IceCat package in Guix sends the same user-agent string as the
'firefox-esr' package in Debian.

      Mark




Information forwarded to bug-guix <at> gnu.org:
bug#45179; Package guix. (Mon, 01 Feb 2021 11:59:01 GMT) Full text and rfc822 format available.

Message #21 received at 45179 <at> debbugs.gnu.org (full text, mbox):

From: Ben Sturmfels <ben <at> sturm.com.au>
To: Mark H Weaver <mhw <at> netris.org>
Cc: Michael Rohleder <mike <at> rohleder.de>, Ben Sturmfels <ben <at> sturm.com.au>,
 45179 <at> debbugs.gnu.org
Subject: Re: bug#45179: qutebrowser stuck at Cloudflare 'browser checks'
Date: Mon, 01 Feb 2021 22:58:28 +1100
On Sun, 24 Jan 2021, Mark H. Weaver wrote:

> ben--- via Bug reports for GNU Guix <bug-guix <at> gnu.org> writes:
>
>> I'm also having similar issues accessing gitlab.com with IceCat.
>> Installing the User Agent Switcher and setting to "Linux / Firefox 82"
>> fixed this for me.
>>
>> For context I also tried starting IceCat up in safe mode and switching
>> tracking protection back to "standard", but no good. The issue appears
>> to be that Cloudflare are essentially blocking niche user agents.
>
> The IceCat package in Guix sends the same user-agent string as the
> 'firefox-esr' package in Debian.

I've done a little more testing for interest sake - I still think
CloudFlare are at fault here.

If use a private tab and attempt to access a private GitLab repository I
get stuck at the CloudFlare "checking your browser message". Here's the
IceCat default user-agent string:

"Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0"

If I install User Agent Switcher and do the same thing, it works. The
only difference in the user-agent string is the version number:

"Mozilla/5.0 (X11; Linux x86_64; rv:82.0) Gecko/20100101 Firefox/82.0"

If I try the same on Firefox ESR on Debian Buster, it works no problem,
but as Mark says, the Firefox user-agent string matches exactly to
IceCat:

"Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0"

That suggests to me that there's more than the user-agent string at play
here.

Regards,
Ben




Information forwarded to bug-guix <at> gnu.org:
bug#45179; Package guix. (Tue, 06 Apr 2021 21:45:02 GMT) Full text and rfc822 format available.

Message #24 received at 45179 <at> debbugs.gnu.org (full text, mbox):

From: "bdju" <bdju <at> tilde.team>
To: "Michael Rohleder" <mike <at> rohleder.de>
Cc: 45179 <at> debbugs.gnu.org
Subject: Re: bug#45179: qutebrowser stuck at Cloudflare 'browser checks'
Date: Tue, 06 Apr 2021 16:41:46 -0500
On Tue Dec 22, 2020 at 10:34 AM CST, Michael Rohleder wrote:
> Hello bdju,
>
> "bdju" <bdju <at> tilde.team> writes:
> > guix (GNU Guix) 91e35e32a4938e0e37499c64fa8ed3e7cf51dce3
> > some example sites with browser checks:
> > https://gitlab.com/users/sign_in
> > http://livechart.me/
> >
> > I already contacted the people in the qutebrowser IRC. The bug persists
> > when I launch with no config (`qutebrowser --temp-basedir'), and they
> > could not reproduce the issue on the same version of qutebrowser I'm
> > using. I suspect it may be an issue with the guix version.
> >
>
> A workaround is setting the "User Agent" string to something CF likes,
> e.g. like this:
> qutebrowser --temp-basedir --set content.headers.user_agent 'Mozilla/5.0
> (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0'
> https://gitlab.com/users/sign_in
>
> Maybe the reason why the (very helpful) #qutebrowser folks can't
> reproduce this, is because they use another qt version (qutebrowser uses
> qtwebengine) and perhaps this sets user agent to a string that CF has
> whitelisted.
>
> I don't think there is much we could do here (besides updating qt and
> mbakke has that in the pipeline, afaik).
>
> --
> COFFEE.EXE Missing - Insert Cup and Press Any Key
While I was able to bypass the cloudflare checks in IceCat with that
User Agent Switcher addon, I found I so far haven't been able to get
past them in qutebrowser by changing my useragent. I tried both your
example and copying one of the useragents generated by UAS in IceCat.
Still caught in a loop. (and I am using --temp-basedir as you said, so
shouldn't be my config)




Information forwarded to bug-guix <at> gnu.org:
bug#45179; Package guix. (Tue, 06 Apr 2021 22:14:01 GMT) Full text and rfc822 format available.

Message #27 received at 45179 <at> debbugs.gnu.org (full text, mbox):

From: "bdju" <bdju <at> tilde.team>
To: "Michael Rohleder" <mike <at> rohleder.de>
Cc: 45179 <at> debbugs.gnu.org
Subject: Re: bug#45179: qutebrowser stuck at Cloudflare 'browser checks'
Date: Tue, 06 Apr 2021 16:56:08 -0500
On Tue Apr 6, 2021 at 4:41 PM CDT, bdju wrote:
> While I was able to bypass the cloudflare checks in IceCat with that
> User Agent Switcher addon, I found I so far haven't been able to get
> past them in qutebrowser by changing my useragent. I tried both your
> example and copying one of the useragents generated by UAS in IceCat.
> Still caught in a loop. (and I am using --temp-basedir as you said, so
> shouldn't be my config)
I was too hasty! I both had to change my useragent and wait a long time!
I didn't measure the time, but I'd guess over 10 minutes for Gitlab to
work. Livechart took even longer. Thanks so much for this workaround.
Oh, and this works without --temp-basedir, by the way. I should be able
to actually use these sites in my normal session now I think!




Reply sent to Michael Rohleder <mike <at> rohleder.de>:
You have taken responsibility. (Wed, 07 Apr 2021 09:56:01 GMT) Full text and rfc822 format available.

Notification sent to "bdju" <bdju <at> tilde.team>:
bug acknowledged by developer. (Wed, 07 Apr 2021 09:56:01 GMT) Full text and rfc822 format available.

Message #32 received at 45179-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Rohleder <mike <at> rohleder.de>
To: "bdju" <bdju <at> tilde.team>
Cc: 45179-done <at> debbugs.gnu.org
Subject: Re: bug#45179: qutebrowser stuck at Cloudflare 'browser checks'
Date: Wed, 07 Apr 2021 11:55:35 +0200
[Message part 1 (text/plain, inline)]
"bdju" <bdju <at> tilde.team> writes:
> On Tue Apr 6, 2021 at 4:41 PM CDT, bdju wrote:
>> While I was able to bypass the cloudflare checks in IceCat with that
>> User Agent Switcher addon, I found I so far haven't been able to get
>> past them in qutebrowser by changing my useragent. I tried both your
>> example and copying one of the useragents generated by UAS in IceCat.
>> Still caught in a loop. (and I am using --temp-basedir as you said, so
>> shouldn't be my config)
> I was too hasty! I both had to change my useragent and wait a long time!
> I didn't measure the time, but I'd guess over 10 minutes for Gitlab to
> work. Livechart took even longer. Thanks so much for this workaround.
> Oh, and this works without --temp-basedir, by the way. I should be able
> to actually use these sites in my normal session now I think!

Yay!  That's great to hear, so let's close this ;)

-- 
Practical people would be more practical if they would take a little
more time for dreaming.   -   J. P. McEvoy
[signature.asc (application/pgp-signature, inline)]

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 05 May 2021 11:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 350 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.