[ previous ] [ next ] [ threads ]
 
 From:  Amaury Amblard-Ladurantie <darcache at gmail dot com>
 To:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Captive portal: more feature requests (web page hosting)
 Date:  Fri, 28 Oct 2005 13:11:18 +0200
Hello

I have been playing a bit with the captive portal (CP) feature of
m0n0wall. I need to host a fully fuctionnal website, with "many" (~5)
pages, which would allow a *non authenticated* user to learn more
about the network, to send a message to the admins if he cannot
connect, or if he needs an account and so on. This website *is* the
captive portal authentication page (as well as few more pages and
forms).

To my opinion, there are a few shortcomings with the current features
of m0n0wall.

1/ There is no simple way of using a complex webpage (or a full
website) as the authentication page

1.a. You can either upload the HTML code (for only one page), but you
have to rely on another server to host any of the files needed to
render the HTML (CSS, JS, images and so on). You can not use PHP on
the authentication page hosted on the firewall. And you cannot host
more than one page.

1.b. You may use "frames" so that the uploaded page uses a frameset
which loads webpages from another server. Or some sort of
<http-equiv="REFRESH" URL="http://foo"> to redirect the browser to
another page In this case, you may use PHP, CGI, Ruby on Rails if you
want to impress people. You can provide many webpages to the non
authenticated user as well.
It is problematic with HTTPS as elements are loaded from different websites.
To my opinion this is however more of an ugly hack than a long term solution.

1.c You may use Paul Taylor's images (thank you Paul BTW for your many
answers) which provides a tool to parse the webpage and detect any
necessary external element. You may then upload the necessary elements
(images), which are then encoded in the config.xml file.
This is an elegant way of hosting one page (and only one page) on the
m0n0wall box itself. However, it the detection of external elements to
encode has some shortcomings (it does not detect images loaded by a
CSS for example). It does not enable PHP use as well.

1.d You may make your own m0n0wall images with a custom CP page. I
don't know if you then can use PHP in this case. This is however not a
large scale solution.


2/ How to solve this problem?

2.a Enable m0n0wall to host a independent website enable to use PHP
webpages. I guess this would require a lot of work, and would not be
compliant (IMHO) with the m0n0wall philosophy, since the disk space
and CPU cost would be significant. You basically want to add a fully
functionnal Apache, with mod_perl/python/whatever to satisfy most of
the needs. And a writable filesystem if you need to store data
submitted through forms for example.

2.b Enable m0n0wall to use an external authentication page. Instead of
uploading said webpage on m0n0wall itself, type in the URL of the page
which needs to be loaded whenever a computer access the captive
network. This way, one can host the website on another server (in my
case, an Apache vhost), enjoy the use of PHP scripts and other
languages which allow for strong user interraction (forms, dynamic
pages...).
There are 2 issues left, one of them dealing with SSL certificates
with vhosts, which has nothing to do with m0n0wall anyway. The last
issue is related to virtual hosting: a single IP address may host many
web servers. This is why m0n0wall must filter the packets going to the
authentication website to make sure only the authorized website is
accessed. The filtering cannot be done based on the IP addresses IMHO,
since only the URL changes (the IP is the same for 2 vhosts on the
same server). m0n0wall has to be able to understand and filter HTTP[S]
packets.
Do you think m0n0wall could provide such a feature in the future?

Thanks, again, for this excellent piece of work.

Best regards,
Amaury