Yes it could work without the element manager.
However, you would then have to rely on a 3rd party computer to host
although the later can be embeded in the HTML code). Therefore you
would have to allow unauthenticated traffic to go through the firewall
and have a 24/7 computer up and running to host the external files.
This is the very reason of the howto: display a fancy login page
*without* having to dig holes in the firewall. Thanks to Paul Taylor's
element manager, this is now possible.
On 11/16/05, Thibodeau, Dale <dthibode at uwc dot edu> wrote:
> Amaury, forgive my lack of html knowledge. Your page looks really nice.
> Could this work without the element manager? I'm testing pfsense and it
> doesn't have element manager.
> -----Original Message-----
> From: Amaury Amblard-Ladurantie [mailto:darcache at gmail dot com]
> Sent: Thursday, November 10, 2005 10:35 AM
> To: m0n0wall at lists dot m0n0 dot ch
> Subject: [m0n0wall] [How-to] display a secured and fancy Captive Portal
> Disclaimer: there is nothing fancy/clever in this email, as it is just a
> quick recap of a method of using a customized captive portal page. I
> performed these steps using Linux, but I guess any other operating
> system applies (the certification generation part may differ, though).
> As more people are willing to offer (un)authenticated access to their
> private internet connection through 802.11x, the "Captive Portal"
> functionalities of m0n0wall provide an interesting solution.
> Here is a way to display a elaborated webpage (instead of the default
> page) to the users who want to connect to the network Since we do not
> want to rely on a 3rd party server to host the webpage elements (because
> that would force us to allow unauthenticated computers to access a
> resource on the network), we will use Paul Taylor's excellent "element
> manager" which enables m0n0wall to store any element directly in the
> configuration file. I used the images available at
> http://inf.imelda.be/downloads/m0n0wall/ since they forbid multiple
> simultaneous accesses with the same username/password ("Disabled
> Concurrent Logins" option). We also want to prevent username/password
> theft (which could lead to a malicious network access), so the
> connection between the client browser and the m0n0wall host needs to be
> 1/ Setup the webpage. A typical webpage relies on many elements:
> - the HTML file itself
> - images
> - flash/java elements (eww)
> - CSS files
> Be careful to link the external elements with a local relative path
> (eg: src="img.png", not src="/assets/img.png"), although I haven't tried
> the latter solution.
> You can use "big" images if you want (after all, since it's local you
> have enough bandwidth), but keep in mind that the images will be stored
> encoded in the config file, and loaded in RAM, so you should'nt use too
> file itself, it is generally considered a good practice to use separate
> 1.a/ As m0n0wall can only host one file for the Captive Portal
> authentication page (you cannot use many pages, or a small website with
> show and hide parts of the page. For example if you need the user to
> agree to the "acceptable use policy", you may want to hide it by default
> (because it is huge and would render ugly), but the user should be able
> to access it easily. You may as well want to remember the username with
> that means). Be aware that no forms (other than the login form) can be
> used on the page without relying on an external server to process the
> form data.
> I designed a static example page of which I can send you an archive if
> you wish. Some screenshots of the webpage will be available here (in a
> few hours):
> 2/ List all the external elements needed by the webpage (images, CSS and
> so on). Do not forget the images loaded by the CSS code.
> 3/ Modify the webpage so the "element manager" will detect any external
> files needed. To do so, if an external element is *not* loaded through
> an <img src="foo" /> tag, add a comment somewhere in the HTML file. For
> example if the CSS loads an image called "bg.png", add this in the
> <body> section of the HTML file.
> <!-- Image needed by the CSS file
> <img src="bg.png" />
> Do this for any element listed in 2/
> 4/ Upload the captive portal authentication page through the m0n0wall
> 5/ Upload the external element in the "Element manager" page. Check that
> all elements listed in 2/ are detected. If not, go back to 3/
> 6/ Create and upload SSL Certificates. This will enable the client to
> submit encrypted username/password during the authentication phase.
> $ openssl genrsa 2048 > captiveportal.key $ openssl req -config
> /var/lib/ssl/openssl.cnf -new -key captiveportal.key > captiveportal.csr
> Remarks: Regarding the "openssl.cnf" location, your mileage may vary.
> Answer the questions (be careful with the common name (CN): it should
> match the captive portal name, eg portal.foo.bar). Do not enter any
> passphrase $ openssl x509 -req -days 365 -in captiveportal.csr -signkey
> captiveportal.key -out captiveportal.crt This certificate will be valid
> one year Paste both "captiveportal.key" and "captiveportal.crt" in the
> appropriate field of the m0n0wall captive portal page, activate the use
> of SSL (which will be used even if you rely on the local user manager).
> 7/ Test the captive portal page and enjoy! :-)
> You may want to do the same for the error page as well (except for the
> SSL generation part of course).
> Hope this will help some of you.
> Thanks to all the contributors (especially Paul Taylor) for the amazing
> Best regards,
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch