[isf-wifidog] Re : Re: WifiDog v2 development update?
dana at nycwireless.net
Mar 7 Avr 02:01:52 EDT 2009
Thanks for this info. We actually use the URL redirect on some
hotspots, but it is not functional enough nor does it do what I was
speaking about in my previous emails.
Right now, with URL redirect, a user is no longer authorized. We don't
care _that_ much about a user identifying themselves, however we do
care _a lot_ about a user agreeing to Terms of Service. In the current
system, once a user is redirected to an external URL, they have free
access to the internet. This is a non-starter for a number of our
What we need is an authorization scheme, whereby a user is directed to
an external URL, and that user can only access that URL or that site.
Only once a user has logged into the external system (which means they
have agreed to TOS) should they be authorized to access the internet
This can be handled via a callback function, using a public/private
signed key with a token passed in by the URL redirect. Such a system
(I believe) provides authorization functionality, as well as being
secure against either a 3rd party attack or a hand-crafted URL (since
the callback must be signed by a private key kept only on the CMS).
The custom portal issue isn't as big a deal as some may think.
Location awareness can be provided to an external CMS by a few
different means, including a lat/long URL parameter or an external
Auth server API that enables a CMS to query the Auth server for the
"location" of a user (based on external IP address and/or user key).
Its possible (though not preferable) to even interject HTTP headers or
URL parameters into a stream via the router (though this obviously
won't work for SSL sites).
Regardless of how we chose to solve the Location awareness issue, as
long as there is a simple authorization mechanism, plugins for various
popular CMSes (including Drupal, WordPress, etc.) are easy to build,
and some folks already have most of the components through various
other Wi-Fi captive portal systems. Even building something from
scratch (which NYCwireless might be willing to do) should be easy if
you have some development skills and the proper documentation.
Executive Director, NYCwireless
dana at nycwireless.net
+1 917 402 0422
NYCwireless is a non-profit organization that advocates for, and
enables the growth of free, public wireless networks
On Apr 6, 2009, at 4:50 PM, Benoit Grégoire wrote:
> > There is an important related question: do you consider the current
> > wifidog and portal to be tied together and form a single product,
> or do
> > you consider them to be separate things and encourage development of
> > other portals using the wifidog server?
> That's a bit of a false dichotomy. The wifidog auth server can send
> users to a custom URL (drupal or otherwise) NOW.
> It has all the infrastructure in place to sent location ans user
> specific variables already in place (as used in the SmartyTemplate)
> content type, it would be trivial to extend the node redirection
> code tu use it to allow crafting URLs automatically, should someone
> have a CMS that can utilise such data.
> The wifidog auth server's Content manager was designed to manage
> highly localized, highly granular content elements in complex
> display scenarios. Few groups actually decided to go in that
> It's pretty obvious that many groups see their portals as either one
> website per hostpot (supported now by custom portal URLs, and easy
> to improve upon) or as a single website with the occasional location-
> specific content element (for which the current Content Manager is
> overdesigned, but there is no easy 'in between" solution that
> doesn't involve everyone coding a custom portal.
> Benoit Grégoire
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
-------------- next part --------------
An HTML attachment was scrubbed...
Plus d'informations sur la liste de diffusion WiFiDog