Hiya, > > b) > > There is no way to login to programatically to online desktop using > > either the dbus api or another manner. This is different to many many > > other web apis and makes it difficult to reliably use the api from > > outside mugshot. > > I don't quite understand this point. The general idea is that the user > *is* logged on, and we barely even support logging out ;-) The general > expectation would be that not being logged in is pretty much the > same as being not connected to the internet. > > But assuming that we fix the lack of a working log out UI, I could > see the need for a D-BUS API to backend a dialog: > > "Conduit needs you to be logged in to online.gnome.org to > perform this operation. Log in now?" > > [ Cancel] [ Login ] > > Where Login would prompt you for authentication. Is this the kind of > thing you are looking for? >
OK. Let me explain what we have in conduit. We support lots of webservices in conduit, which means we have login code and experience for each one. As it turns out, most web login systems fall into two categories and require very little login logic. The two types of logins are; a) The ability to log in programatically. Call methodFoo(secretKey) on the server and get back a authentication frob to use in all subsequent calls b) Two step login. e.g. call methodLogin(user) on the server, which brings up a web browser, you log in then you call methodGetFrob(username) and you get your magic frob. Frob does not always equal a cookie IIRC. a) doesnt involve web-login-driver and/or ddm at all. Its not needed (beyond the 'what is my username on this service' type config we already discussed) My problem with the current implementation is that is doesnt reliably solve B in all cases. For example - we are concerned with the initial[1] login experience in conduit. Lets say you want to upload some photos to $WEBAPP from eye of gnome (i.e. you may treat Conduit as a DBus service - dont even start its gui). The first time the user ever does this they need to login to said $WEBAPP using a browser. If that is the case, it allows us a much cleaner [2] experiece if Conduit pops up a small site-specific-browser to allow the user to log in, rather than starting firefox which has its own problems, its hugeness, it not reliably getting the users attention, 26 other open tabs, session saver extension/restore previously crashed session, etc [3]). [1] The 'initial' experience actually happens quite a lot for some webservices - for example box.net logins only stay valid for a few hours. This means that you must re-login to the webservice almost every day. If this is the case it seems convoluted to go with the mugshot approach - switch to a browser, login, wait for it to pick up the cookie, get the cookie from mugshot, turn the cookie into a from that the box.net api needs (is this even possible in the general case?) [2] Their are some other hairy things here like there is no way to reliably start a new browsing session that blocks the caller (which is needed because many webservices invalidate the login if you call getFrob() before the user has logged in). So to come back to your question - I dont really want a seperate login dialog for online desktop (at least not as the final solution), I just would like online desktop to offer a login process that is more similar to all other $WEBAPPS and that allows a consistant login experience when authenticating, whether for the 0th, 1st, or nth time. And if we do have to authenticate then at least give us the option of not starting the whole system browser to do a simple 2 second login. Until something like a or b is possible Its a bit hard to make conduits round peg fit into online desktop square hole - especially when all other webservice login methods have roundish holes or holes of an oval nature. I know you think of online deskop as different, a always logged in type scenario, but that doesnt fit my use-case for it, and becomes even hairier when I cant get it to consistantly log in. I would really appreciate if you could check conduit out from SVN and play with how it logs into things using its built in web browser for and idea of what I mean [3]. [3] caveat: as I mentioned in my blog post, SVN head is a bit rocky atm. > > c) > > Continuing on from the above point, the current method of monitoring > > and parsing the cookie file to log in, while cute, is not something I > > totally grok. While I see the point of it all (login once, and then > > access the services from any app) It never gets close to solving the > > real problem, sharing authenticating information from the browser with > > the rest of the system. web-login-driver is neither here nor there as > > a solution, it adds another running daemon for very little benefit, as > > the final step in the process (rewriting the cookie file so the > > browser can pickup external logins) is not implemented. > > I think you are mixing together two different things here: > > - The way the mugshot client logs into mugshot.org and/or > online.gnome.org. No, that was really my previous question. > - Our attempts to improve the general problem of authentication to > services across the desktop. (web-login-driver is part of that) > > I guess, to some extent, online.gnome.org *is* just another service, but > we're not really considering it that way. We consider the instant > notification aspects of what we are doing an integral part, and the > natural way to do that across the desktop is to have a single daemon log > in once, rather than have each client open a separate XMPP connection to > online.gnome.org. > > Adding a more standard web-services API for third party access to > online.gnome.org is certainly 100% possible; I even have some code > started for that around somewhere. It's just not a priority for us at > the moment, since we're focused on the use of online.gnome.org inside > the GNOME desktop. I would like to see this, or atleast some additions to the DBus api to allow a,or b > > I appreciate your mail; it's great to have other people trying to work > with our services and finding out what works for them and what doesn't. > I hope the above makes it more clear how we see access to > online.gnome.org integrating with the desktop. Cool, me to. Remember that I also have ideas on how to make it integrate with the desktop, particualry from the perspective of "each gnome user has a reliable online space they can sync stuff to without configuration" John _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
