[isf-wifidog] Re : Re: WifiDog v2 development update?

[wlanmac]

While on the topic of location awareness, here is something that might
be of interest from the world of NAS/AAA:

http://tools.ietf.org/html/draft-ietf-geopriv-radius-lo-23

Standards are good!

David

On Tue, 2009-04-07 at 02:01 -0400, Dana Spiegel wrote:
> Benoit,
> 
> 
> 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
> hotspots.
> 
> 
> 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
> in general.
> 
> 
> 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.
> 
> 
> Dana Spiegel
> 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
> > direction.
> > 
> > 
> > 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
> > http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
> 
> 
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog