David Rodgers wrote:
> OK ... I didn't really like the captive portal idea but since it's already
> this far how about the next logical step .....
Luckily it can be disabled (indeed this is the default state). As I
understand it, there is no overhead or possibility of security issues
when the portal feature is disabled.
> How about an authentication option that can be enabled for the portal to allow
> you to controls users via a radius server? Just a click box that adds a
> userid and password field to the aup form and uses radius authentication.
This can already be achieved (more or less) by pasting in the right
HTML code. That being said, I think Manuel et.al. is already working
on something along these lines, albeit in a more flexible way:
If I remember correctly, the plan is to remove the auto-generated
button, and instead preload the HTML box with the code for the button.
This way you can either choose to elaborate on the HTML code, or you
can simply do a redirect to some auth. page (such as radius). It
should then be possible to authorize a user by throwing a HTTP
response at m0n0wall (similar to that generated by the preloaded code
for the button i guess?)
While perhaps not as easy to set up, this should provide for a more
flexible system, allowing you to do more or less whatever you fancy
with the portal page.
Additionally, I got the impression that a white-list feature is also
under way, in the form of a list where you can enter a number of MAC
addresses which are allowed to bypass the portal page entirely.
I hope this fits your bill? It certainly does mine, but then again,
I'm not really in need of a portal, I'm just playing around with it
for my WLAN guests at home, mainly for the coolness factor ;)