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

[Dana Spiegel]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listes.ilesansfil.org/pipermail/wifidog/attachments/20090407/05d698d6/attachment.htm