Captive Portal not working anymore

  • The Captive portal is not working anymore.
    After inputting the Username and Password, there is nothing happening. Even if the password is wrong, the error page is not showing.
    In the log I can see the following error: "Jan 19 23:39:25 php-fpm 42505 /index.php: Submission to captiveportal with unknown parameter zone:"

    Also, the "View current page" button in the "Auth error page" section, doesn't show the error page. If I click on the "View current page" button I get redirected to /services_captiveportal.php?zone=wifiportal&act=viewerrhtml, but I think it should be /services_captiveportal.php?zone=wifiportal&act=viewerrhtml in order for the link to work.
    Also, the "View current page" button link for the "Portal page contents" should be /services_captiveportal.php?zone=wifiportal&act=viewhtml.
    It seems that the view button for the "Logout page contents" is the only one correct.  :D

  • Developer Netgate

    Just pushed a fix for the &amp issue.

    So far we have been unable to reproduce your first issue. Just set up and tested a new CP and i seems to work as expected. You might check your HTML or share it here for checking.

  • Indeed, using the default page for captive portal, everything is working…

    After more testing I discovered that the default captive portal page contains an additional hidden field: ""
    After adding the above line to the custom page that I am using, everything started working correctly.
    The thing is that I didn't made any modification and the page was working in the past without the additional "zone" field.

    I think that the instructions on services_captiveportal.php should be updated to state that the page also need to have the hidden field name="zone" and value="$PORTAL_ZONE$".
    I attached the files that I was using and worked until some time ago (I discovered the issue 2 days ago, but I don't know then it appeared... maybe at the migration from lighttpd to nginx) if you need to inspect them further.


  • Yeah it was the migration to nginx that made that field necessary. I was looking at possible fixes yesterday and haven't had time to get back to it yet. Rather than breaking every custom portal page out there, we should be able to fix it in the URL it's filling in.

Log in to reply