On 24 September 2010 08:59, Kees Cook <kees.c...@canonical.com> wrote: >> Pretty much every third-party developer (and at least one internal >> developer) has responded to our OAuth token authorization protocol by >> hacking around it, creating some native-GUI way of asking the user for >> their Launchpad username and password, so that their users don't have >> to do the browser dance. > > Why not offer a non-browser way to do this? Gnome-keyring is effectively > holding the "authentication token", and could go fetch a new "session > token" for different applications, etc. Why confine the session management > to the browser?
Because Launchpad has no concept of logging in other than by OpenID, and that means sending the user to a web page in a (probably graphical) browser. See <http://pastebin.ubuntu.com/499131> around line 160. For me it's analogous to PAM, which in principle may do any arbitrary action to authenticate the user but for many useful cases is actually going to have a text dialog that can be remapped into a graphical greeter or whatever. I think accepting openid is great, but it if the user does have a Canonical username and password it's being pointlessly stubborn not to let them use it. At the moment all our users are in this category. This, to me, is also an example of where we're not listening to what our api clients want to do. One way to improve this would be to ship some code that, given a user name and password, logs in to Canonical SSO. This code already apparently exists in some clients; we might as well acknowledge the fact and make it properly supported subject to the caveat that eventually some users may not have Canonical passwords. -- Martin _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
