[BUG] AntiBot JavaScript Challenge redirect to "/" after challenge ?

[guldil]

What happened?

I have enabled the AntiBot Challenge in "JavaScript".
I'm testing on a URL such as https://www.example.com/my-page
I'm closing Browser, start a new session and copy and paste the URL.
In Firefox, I am correctly redirected to "my-page" after the challenge.
In Chrome, I am redirected to the site’s root, "/".

Did i miss something ?

How to reproduce?

I'm testing on a URL such as https://www.example.com/my-page
I'm closing Browser, start a new session and copy and paste the URL.
In Firefox, I am correctly redirected to "my-page" after the challenge.
In Chrome, I am redirected to the site’s root, "/".

Configuration file(s) (yaml or .env)

Relevant log output

BunkerWeb version

1.6.11

What integration are you using?

Docker

Linux distribution (if applicable)

No response

Removed private data

• I have removed all private data from the configuration file and the logs

Code of Conduct

• I agree to follow this project's Code of Conduct

[TheophileDiot]

Hey @guldil, thanks for the clear report. The Firefox vs Chrome detail is what made it click.

We found the cause. With the JavaScript challenge, BunkerWeb remembers the page you originally asked for (your /my-page) and sends you back there once you solve the challenge. That target gets stored in your session cookie, which only gets set on the very first request.

The trouble is that Chrome fires off extra requests that Firefox doesn't. When you type or paste a URL, Chrome will often preload/prerender it and grab /favicon.ico right away. On a brand new session those requests can arrive before the cookie from your real page load has been saved. When that happens, BunkerWeb ends up setting up the challenge for one of those background requests instead, and since a favicon (or the challenge page itself) has no "real" destination, it falls back to /. You then solve the challenge against that, and it drops you on the home page. Firefox grabs the favicon later, after the cookie is already set, so it keeps the right page.

The fix makes this reliable no matter what the browser does. The destination now travels in the challenge URL and the challenge form itself, so it survives even if one of those background requests wins the race. On top of that, BunkerWeb now only records the destination from genuine page navigations (it reads the Sec-Fetch headers the browser sends), so favicon and preload requests can't overwrite it with / anymore.

We've tested it against real Chrome and Firefox and it now lands on the deep link in both.

Couple of things that would help us match your exact setup:

• Are you on the default cookie sessions, or do you have Redis enabled (USE_REDIS=yes)?
• Single site or multisite, and is the deep URL on the same hostname as the home page?

One heads up for the meantime: there isn't a clean config workaround. Turning on Redis might make it happen less often but won't fully stop it, since the real trigger is the timing of Chrome's background requests. The code fix is the actual solution.

[guldil]

I’m already using REDIS (I have two bunkerweb instances in HA mode behind haproxy) and it is indeed a multisite configuration; I have two services.

[TheophileDiot]

Thanks, that's useful and it actually lines up with what we expected. Redis only changes where the session contents are stored; the race is over which session id your browser keeps when Chrome fires its parallel requests on a fresh load, and that happens the same way with Redis as without. HA (two instances behind HAProxy on shared Redis) and multisite don't change it either.

The fix doesn't depend on any of that. The destination now travels in the challenge URL itself and is re-derived from each real navigation, so you end up on the right page no matter which instance serves the request or which background request wins the race. No config change needed on your side once it ships.

[guldil]

Hi Théo,

What do I need to do to get this fix?

Thanks a lot :)

[TheophileDiot]

You just have to wait for the next release 😄

[TheophileDiot]

Hi @guldil, the 1.6.12~rc3 is out if you want to give it a spin 😄