Custom captive portal

[ghost]

I am looking to use a pi as an access point, but to have the option of connecting to a wifi router as well. Comitup provides those options, but the current captive portal takes me straight to the choice of which wifi I would like to connect to, when in many instances I will not need to connect to wifi and would rather provide a link to my app.

I would like then to change the index.html captive portal page to one I have built myself, providing options such as "redirect to page of my choosing", "redirect to page of my choosing2", "setup wifi connection (this one being a link to http://10.41.0.1/)".

If I add this custom index.html file into the /web/templates folder, rename the existing index.html to captiveportal.html, and change all the references to index.html in the code to captiveportal.html do you foresee any issues?

Alternatively, can the captive portal option be disabled (not such a good option, but perhaps simpler)?

Finally, (and I believe this request is already under consideration), if the captive portal is disabled, is there a means of changing the default port for Comitup from port 80 to something else, freeing up port 80 for me to run a webserver in access point mode that can be accessed through a browser without needing to specify :portnumber at the end of the URL? When combined with disabling captive portal, I can then have a custom index.html page hosted at hostname.local that provides my three options, one of which forwards to http://10.41.0.1:portnumber.

Running on Raspberry pi Zero, Buster lite and using the comitup GitHub repository.

[davesteele]

If you know what you are doing, you can update the Flask web templates to show just your access point, and to point to your app. If you move the original index page/template, the reference in the Flask server implementation would need to be moved as well. Note that if you use the Comiitup image, by default new versions of the comitup package will overwrite your changes.

There are a number of strategies for implementing captive portals. The oldest, and still the fallback, is to force DNS to always return the IP address of the portal for all queries. So all web requests go to the portal web server, which then redirects all unknown requests to index.html. To make this work, the captive portal web page reference is hard coded in the server app software, and the portal web page must use the same port as the original request, 80. If the portal web server were on another port, then the server at port 80 would be responsible for the redirects to it. This might not be that hard to do, but I haven't tried it.

[ghost]

Thanks, for your help.

Thinking about it further, if I change the templates and then the pi connects to a wifi network, the comitup flask service goes down, meaning I won't be able to use it to navigate in both the access point and wifi hub connected instances anyway. I realise I could keep the comitup flash service up but seems unnecessary when a NGINX server is running all the time that can do the work.

That leaves me with changing Comitup to another port and disabling the captive portal. I see that in #61 port changes are made in comitupweb.py with some success, can you foresee any repercussions to consider? Would doing this disable the captive portal, as I assume it then won't be able to find the web server on the new port if the addresses are hardcoded?

As a bit of background, this will be rolled out without much ability for me to provide changes or updates, so rather than relying merely on my limited testing, thought it best to run it by those who might be able to foresee issues.

[davesteele]

You could set web-service to comitup-web, and the server would essentially stay up, but that server has not been tested in CONNECTED mode.

I'd move the portal web server to another port, and set up your server to link it, and to redirect all unknown pages to it. You may have to rework the DHCP option as well.

[ghost]

Things seem to work well with the port change, thanks for the input. I haven't done any changes to the DHCP option and things seem to be ok, let me know if I am missing something there.

I was hoping not to do anything as extreme as redirect all missing pages to comitup, it could cause issues later on if I get broken links, or users typing an address wrong (unlikely, but figure its good practice not to redirect all pages). As expected, the captive portal doesn't appear now the port has change.

I considered a few other alternatives, just forwarding the pages that will be queried, moving the flask files over to NGINX or running a parallel captive portal, but they all run the risk of potential issues when comitup updates from the repository and files get overwritten or changed. At the moment the only thing I will need to adjust is the port number in comitupweb.py, which is more manageable from a maintenance perspective.

I would add one up vote to making the port a variable in the .conf file, that way it will be maintained during comitup updates. It would need the caveat in the docs that this would disable the captive portal. Alternatively, the various references in the code to 10.41.0.1 could be changed to 10.41.0.1:$var so it follows the server around based on what port it is on, but that is beyond my abilities to implement and test thoroughly enough, wish I could have helped.

[ghost]

Urgh, you were referring to forwarding all unknown pages to the NGINX server, realised just after sending the message. Of course, just tested and that works great, thanks!

Would still be useful to have the port as a variable in the .conf file though is that's an option.

Slightly off topic, to delete a network I am using comitup-cli from your man pages, then select 'd'. Would be good to be able to pass that all in one command so I can use it in a script on a webpage. 'comitup-cli -d' for example would be helpful.