Captive Portal shows 404 post login after upgrade to 2.4.5

[eroji]

I just upgraded to 2.4.5 and when a user signs in via Captive Portal it immediately shows a "404 Not Found" nginx error. I have the After Authentication Redirect turned on, but that is not working at all. Disabling that options also yields the same 404 page. Anyone else experiencing this?

[eroji]

I figured out the issue. It appears to be configuration problem, possible as a result of the upgrade. The default redirect URL I had configured was https://www.google.com. Somehow, it put that was the "After authentication Redirection URL" which was the variable $portal_redirurl$. After switching these 2 values in the configuration, it's now working.

[Gertjan]

@eroji said in Captive Portal shows 404 post login after upgrade to 2.4.5:

It appears to be configuration problem, possible as a result of the upgrade

The upgrade didn't change the configuration settings.
What did change is the way how redirecting was applied. This is the way thing were done before ( 2.4.4-p3 and before) :

First, if "After authentication Redirection URL" (= $cpcfg['redirurl']) is set, the redirect URL is set to that.
If not, if the initial request ( == $orig_request) exists, the browser will get redirected to that site/page.
If not, if a browser REQUEST URL contains "redirurl" as a parameter,, then that gets used.

Test 1 forces the visitor to be redirected to the "After authentication Redirection URL" URL.

With 2.4.5 that changed :

First, if the initial request ( == $orig_request) exists, the browser will get redirected to that site/page.
If not, if a browser REQUEST URL contains "redirurl" as a parameter,, then that gets used.
If not, if ""After authentication Redirection URL" (= $cpcfg['redirurl']) is set, the redirect URL is set to that.

So, "After authentication Redirection URL" only gets used if the first 2 test are false.

Note : test 1 seems a bit awkward. $orig_request == $_REQUEST['redirurl'] is tested (grep) for the string "redirurl=(.*)", or it should contain an URL, not something like "redirurl= http://captive.apple.com/hotspot-detect.html" - I guess this test always fails ....
Test 2 is (nearly) always going to be true because the visitors browser will use an initial test "http" URL - iPhone = http://captive.apple.com/hotspot-detect.html so, after ID ok, it should be directed to this URL ...

Btw : this new behaviour, IMHO, is not what the description tells us :

Set a forced redirection URL. Clients will be redirected to this URL instead of the one they initially tried to access after they've authenticated.

test 3 will use the "After authentication Redirection URL" URL. I guess this will happen if the user is visiting the captive portal the explicit way, using an URL like

http://1.2.3.4:8002/index.php?zone=cpzone

where 1.2.2.4:8002 is your pfSense portal interface and port
cpzone = the captive portal zone name.

Note : the nginx redirection logic :

		if ($http_host ~* 1.2.4.4) {
			set $cp_redirect no;
		}
		if ($http_host ~* yourportal.pfsense.tld) {
			set $cp_redirect no;
		}

		if ($cp_redirect = '') {
			rewrite	^ /index.php?zone=cpzone1&redirurl=$request_uri break;
		}

side note :

		if ($cp_redirect = '') {

is bad and makes nginx throwing out a warning : a variable is used with initing it first.
Somewhere higher up in the config this should be there :

		set $cp_redirect '';

end side note.

For myself, I didn't notice this behaviour, because I'm using FreeRadius as an identification source, and in that case, the Redirection URL is taken from FreeRadius and handled the 'correct' way.