Re: Network Manager Autologin

[Dan Williams <dcbw redhat com>]

On Fri, 2008-11-07 at 16:37 -0500, Slokunshialgo wrote:
> On Tue, 2008-11-04 at 13:46 -0500, Dan Williams wrote:
> > On Tue, 2008-11-04 at 15:54 +0100, Pablo Martí wrote:
> > > On Tue, Nov 4, 2008 at 3:21 PM, Alexander Sack <asac jwsdot com> wrote:
> > > > On Tue, Nov 04, 2008 at 03:11:13PM +0100, Pablo Martí wrote:
> > > >> Sure! I also think that the Firefox approach is not the right one, is
> > > >> just that I'm not very fond on NM's dispatcher
> > > >> architecture/capabilities. I kinda like the description/mockup given
> > > >> here [0]. Marcelo asked in nm-list 1 year ago and he was pointed to a
> > > >> dispatcher script[1].
> > > >>
> > > >> [0] http://blog.marcelotoledo.org/2007/09/01/network-manager-with-wispr-support/
> > > >> [1] http://mail.gnome.org/archives/networkmanager-list/2007-September/msg00002.html
> > > >>
> > > >
> > > > OK thanks for the links. I really think this can be done outside of NM
> > > > applet to things started.
> > > >
> > > > Writing a wispr-applet that listens to D-Bus events from NM and which
> > > > does the wispr probing and authentication business should be fairly
> > > > easy.
> > > 
> > > Thanks for the input Alexander, much appreciated. What do other
> > > developers think of this approach? Tambet? Dan?
> > 
> > Shouldn't be part of NM, but NM should expose all the necessary
> > information to allow auto-login to be possible using external tools.
> 
> This makes sense, and is what I was thinking
> 
> > If that includes requesting WSP information explicitly from the DHCP
> > server, that's great, we should add that.  The DHCP information is
> > already exposed over D-Bus and thus any app that listens for NM events
> > should be able to get it.
> 
> What exactly is WSP?  I can't seem to find anything on it.
> 
> > You can tie specific logins pretty easily to each connection's UUID,
> > thus if you know that your "Starbucks" connection just came up (as
> > opposed to any other connection) you could certainly match that up with
> > stored credentials and try to auto-login with those first before doing
> > any probing or whatever.  Basically, if the AP is at least WPA
> > encrypted, and NM connected, there's a 95% chance that nobody is
> > spoofing the connection, and that you really are connected to Starbucks,
> > so you can save some time probing by just trying stored Starbucks auth
> > info first, maybe.
> > 
> > Dan
> 
> The problem I see with using WISPr is that not all networks support it
> (the ones I have to log into, for example, don't), and if something was
> to be made it should work on any network.
> 
> I know that this may seem like I'm overly invested or interested in the
> idea of using Firefox, but I'm looking at it from the standpoint of
> flexibility:
> - If it's not a WISPr network, it would still work
> - If the site needs any special javascript, popups, etc. they can be
> taken care of as per manual login
> - If there are any weird login errors, it's easier for the user to see &
> debug
> 
> > Do we have per-user dispatcher scripts or are you suggesting to open
> > the browser as root here :) ?
> >
> > - Alexander
> 
> God no!
> 
> Reading what you guys have said, how does this sound?
> - Store the login page URL in NM, and transmit this along with other
> info when connecting, in case anything else wants to use it

Again, I don't think this should be or needs to be stored in NM at this
time...  NM connections have a UUID, so you can store the data in the
daemon that keys off the UUID when connections change.  Going forward we
can try to design a more comprehensive "get me an internet connection"
mechanism.

Dan

> - Have an external program listening for the DBus signals, and, when
> picked up, check if FF is running.  If not, start it
> - Pass these along to Firefox, which would have an extension listening
> for the external program
> - FF would go to the page and automatically log in to the page, and
> allow the user access to the network
> 
> I'm saying to store the URL in NM in case somebody want to make
> something for another browser, or using Python, curl, etc. it could
> still use it.  If it transmits the info and nothing puts it to use, no
> harm is done.  The external program would be running with user
> permissions, not root, even if just to appease Alexander.
> 
> I know I need to look into exactly what info is sent, but how does this
> sound so far?
> 
> --Jason
>