Re: Online Desktop and GNOME 2.22

["John Stowers" <john stowers lists gmail com>]

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