[isf-wifidog] Future Idea Dump
Benoit Grégoire
bock at step.polymtl.ca
Lun 15 Mai 10:27:00 EDT 2006
> Thoughts
>
> 1) Separate out wifidog and auth server and publish messaging
> protocols. I think this will give people the option of developing
> their our auth-servers/content servers etc, and allow a shared wifidog
> distribution.
That will happen with the protocol redesign, but there is otherwise very
little incentive to spend any time on it. As far as I remember, the only
patch to the gateway to ever to come from outsite ISF so far was from
wireless london. If the groups using forked/alternate auth service want it
faster, they will probably need to write the first draft of the document
themselves on the wiki.
> 2) User Mac. Is this sent with the login/auth requests ? It would be
> handy to have it passed to the auth server
It is, and it is used by the auth server.
> 3) Login options. LW has various options and control levels given the
> possible parameters of user+pass+mac.
> a) Splash only - no login, just terms
> b) User+pass
> c) mac only - whitelist, auto login (staff perhaps)
> d) user+pass+mac (locked down) - admin user
a and b are already supported. c is only supported by specifying it on the
gateway side. Moving it to the server is ticked
http://dev.wifidog.org/ticket/76, but will require a protocol redesign and
major gateway surgery. The problem is that MAC-whitelisted addresses need to
be whitelisted for all ports, so they must be permanently included in the
firewall, they cannot wait until an http connection triggers wifidog into
asking the server. So they will have to be updated on a regular basis when
the counters are updated. As the list could get quite long, we should
probably hash it, send the hash and send an update request only if the hash
changes.
> 4) User realm/dimension. A gateway is a node, and belongs to a
> network. A user belongs to a network, but a network can be affiliate
> with other networks to allow user account sharing. Makes the admin
> reporting more complex, but may increase take up with business. i.e.
> coffee shop is a node, coffee chain is a network, it may affiliate
> with book shop chain network.
These are actually two different features. One is network peering, which is
planned for (the auth server was designed with it in mind, reporting would
already work out of the box). The second is node groups, allowing treating a
group of nodes as an administrative entity.
> 5) Walled garden.
>
> Users are allowed to visit without logging. Means user traffic is not
> logged (no connection id), but allows a network to give user access to
> its own sites etc without login.
>
> LW does this with a 15 minute cron job that sets up the walled list as
> IP chain.
No need for that, it's already supported by the gateway. Moving it to the
auth server will be done with the previously mentioned protocol redesign.
> 6) Throttle.
>
> While you can build a real complex system, the actual requirement is
> throttle heavy users, or the whole system when its under load. A
> secondary pitch is for community meshes where business hosts nodes and
> throttle access during the day and then open it up when they don't use
> it.
>
> In reality I think you only need three bands high,med,low , and then
> assign a user to one of them. LW gets the band during login, but with
> wifidog, you could use it a part of the auth update to reallocate a
> user to a new band. If you wanted to get really techie, then the auth
> server could auto manage it.
See tickets 24 to 27. We spent a lot of time thinking this over, and the
multi-band idea simply doesn't solve (or even help) the problems in our case.
While it may solve it for some other cases, implementing it if ticket 27 is
implemented is trivial on the auth server. Doing it without ticket 27 pretty
ties us to the multi-band way of doing things, unless it's an optionally
compilable gateway module.
> 7) Tickets.
>
> Public ip sets up tick users with time limits or download limits, you
> should be able to monitor this, and use the auth server to remove the
> user.
That's very easy to add on the auth server, but no current group using wifidog
expressed a need for this functionality or interest in implementing it.
Quite frankly it's mostly usefull in commercial contexts, making it somewhat
unlikely someone would implement it on their free time.
> 8) MyStatus/Messaging.
>
> PublicIp does use windows messaging to sent time left/node messages to
> the user, but this relies on the user having windows.
>
> If would be nice if with a DNS redirect the user types
> http://wifistatus/ , and gets their stats, login times, node closure
> time. I can't think of any other way of informing a user when they are
> going to be kicked off due to node opening hours etc.
Captive DNS is part of a branch of the gateway, but was never merged back in.
However, it probably wouldn't solve your problem. Your user would still have
to take active action to get the information, which is useless to tell him he
is about to get kicked out.
Three things are related to this:
-Allow the user to easily come back to the portal (ticket 4) (captive dns
would help with this)
-Getting self-statistics, which should be done as part of my work on profiles.
-User messaging
-User intrusive messaging
Intrusive messaging (I'd like to keep the name, it reminds whoever uses it of
what it actually does...) could be implemented as a new token
state "USER_HAS_INTRUSIVE_MESSAGE". Upon receiving this, the gateway
wouldn't remove net access from the firewall, but would re-activate the http
redirect, redirecting to the message on the auth server (a simple page with a
continue button that would clear the toke state using the same flow as the
login process, and then redirect to the user's original http request.
I hope to continue this really interesting discussion!
More information about the WiFiDog
mailing list