Excellent, thanks a lot for your input.
Sorry about my first questions for which, according to your reply, an
answer may have easily been found with a bit more reseach.
On 10/25/05, Paul Taylor <PaulTaylor at winn dash dixie dot com> wrote:
> In version 1.2 you can use a local user manager, which is built-in
> to Monowall. Also, in version 1.2, you can select to run the portal on
> HTTPS. People attempting to connect will automatically be redirected to the
> HTTPS page. If they try to go to port 8000, I believe that also redirects
> to the HTTPS page...
> Your last feature request, to host "captive portal web page
> elements" on the Monowall server is something that I also needed. I have a
> version of software that adds a new tab to the Captive Portal admin pages,
> called Element Manager. This allows you to upload a captive portal login
> and/or error page, then go to the Element Manager tab. It will parse the
> login/error page and list the elements that it thinks it should host
> (images, css, etc.) and allow you to browse to those files on your local
> hard drive and upload them. Once uploaded, they are stored encoded in the
> config.xml file and served when requested through the captive portal page.
> My custom version with this (and other features) has been released here:
> for the generic-pc version, or this link for the cdrom version:
> Note that this is based on 1.2 beta 10, which is very close to the final
> 1.2. There were a few minor bug fixes and OpenVPN was removed.
> And to answer your last question, you can't run PHP code in your login/error
> pages. HTML only...
> -----Original Message-----
> From: Amaury Amblard-Ladurantie [mailto:darcache at gmail dot com]
> Sent: Tuesday, October 25, 2005 10:12 AM
> To: m0n0wall dash dev at lists dot m0n0 dot ch
> Subject: [m0n0wall-dev] [Captive portal] Questions/feat reqs (radius, HTTPS,
> Let me start by saying that I have been greatly impressed by the
> m0n0wal project. So many functionnalities so easily accessible is
> something many commercial vendors would like to acheive.
> I have been using m0n0wall as a router/firewall on some old hardware
> for a few years now and have been very happy about it. I would like to
> use the "captive portal" feature in order to provide internet access
> to friends (I am planning on adding a third interface and plugging in
> a "dumb" wifi AP). I have read the documentation and searched the
> mailing-lists, and most of my questions have been answered. I have
> however a few questions/requests for features (hence the post on the
> -devel ML) left regarding the captive portal.
> 1/ Non radius/ local authentication
> I know most (if not all) captive portals use a separate authentication
> servers, most often based on radius. I don't see any security
> requirement for that, and I wonder if it would be possible to use a
> *local* authentication base (using radius or just passwd type flat
> files), which would allow m0n0wall not to be dependent on another
> I find it a bit to inapropriate to install a radius server just to
> check a couple of login/passwords, where a standard Unix type
> authentication system would be perfectly suited IMHO.
> Or would it be possible to include a radius server in m0n0wall for the
> same benefit?
> 2/ HTTPS portal page
> The portal page is accessible via HTTP on port 8000, and via HTTPS on port
> Is it possible to force users to authenticate using the encrypted web
> page and to prevent them using the clear text web page?
> 3/ Portal page customization
> If I read the documentation correctly, the only way to customize the
> "captive portal" web page is to upload a file, and, if any image, CSS
> address in the "authorized IP addresses" list.
> I see many drawbacks with this approach:
> - the pf rule applied for the "autorized IP addresses" list is the
> same before and after authentication. However, only HTTP/HTTPS is
> needed before authentication, and since I don't trust the client
> before the authentication, I don't want them to connect to anything
> else rather than 80 for example. Once they have successfully
> authentified I have no problem changing the filtering rules to allow
> them to access other services on that IP address.
> - many websites use "Virtual hosting". I don't want non authenticated
> users to be able to access the other websites hosted on that server.
> This could be solved by DNS restriction but since I guess we are
> dealing with IP filtering, it is out of question.
> - the captive portal web page elements which cannot be hosted on the
> m0n0wall (images, CSS etc) have to be hosted on a public website on
> the Internet (hosting them on an internal secured website is not
> acceptable to me as I have no internal server running 24/7). It means
> unless I configure some filtering solution to reject any IP address
> but my m0n0wall IP address (what to do then when the public IP address
> is dynamic), anyone will be able to download the components of the
> captive portal web page, which should remain private IMHO.
> Is it possible to upload all the captive portal web page components
> onto the m0n0wall computer itself rather than having to rely on
> another server ?
> If yes, is there a *simple* way of doing so (other than mounting &
> hacking the m0n0wall disk image) ?
> if not, are you planning no developping such a feature ?
> And, finally, is it possible to upload PHP code as the captive portal
> web page which would be interpreted at run time or is it limited to
> HTML ?
> Thank you for your help, and congratulations to all the contributors
> of the project for this amazing achievement.
> Best regards,
> To unsubscribe, e-mail: m0n0wall dash dev dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash dev dash help at lists dot m0n0 dot ch