launchpad-dev team mailing list archive

[Abel Deuring <abel.deuring@xxxxxxxxxxxxx>]

On 24.09.2010 00:25, Leonard Richardson wrote:
[...]
> Here's the problem: my developers will not put up with that. They
> don't put up with it now, and they won't suddenly start putting up
> with it if the security benefits ever become real.
> 
> 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.

Perhaps I don't get the point, but if people write their own GUIs to
replace the browser dance, I assume that the main problem is that some
GUIs do not ask the user if they want to allow write access or access to
private data.

Couldn't we write libraries for GTK/QT/... [1] which provide GUIs that
let the user set public/private and read/write options and which then
get the OAuth token from Launchpad?

That makes life easier for the third-party developers and it allows us
"enforce" (or at least to recommend) that users are able to set the
access level of an LP API client.

Abel

[1] yes, I know,
len(('GTK', 'QT',...)) * len(('Python', 'Java', 'C',...)) is not a very
small number -- but how many languages and graphical libraries are at
present in real use for LP API clients?