Captive Portal shows 404 post login after upgrade to 2.4.5



  • 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?



  • 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.



  • @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.


Log in to reply