launchpadlib users made to authenticate unnecessarily

Francis asked me to investigate the anonymous creation of OAuth credentials. Here's how the workflow could go:

Right now when you start launchpadlib without giving it a set of credentials, you get sent to the credential creation page. You must be logged in to access this page.

Under the new system, you'd be able to see the credential creation page without logging in. In addition to the different types of credentials you can create now, you'd be able to create an anonymous credential. This would take effect as soon as you clicked the button for it.

The other kinds of credentials would only be created once you'd logged in. If you happened to already be logged in through your web browser when you started launchpadlib, you'd be able to create any kind of credential with one click, the way you can now.

Basically we move the point of login to just before the credential is created.

If we do this there will not be much difference between an anonymous credential and a public-read credential associated with a user. The only difference is that there's no way to revoke an anonymous credential. This is a serious problem and I don't have a good answer for it. We'd either need a way of claiming a credential after the fact, or a one-off revocation protocol.

Even the ability to claim a credential after the fact won't help people who never create a Launchpad account. OTOH, I'm overreacting, because an anonymous credential isn't worth revoking. A malicious application with an anonymous credential can't view private data or modify the dataset--can't, in short, do anything to hurt you. And can't defame you because the credential isn't tied to you. So the only real problem is a likely proliferation of anonymous credentials.

Talked with Salgado. If we do need the ability to revoke anonymous credentials (which I doubt) here are some possibilities:

* Anonymous credentials could expire after a limited time--say a month.
* We could publish a form on Launchpad (which didn't require login) which takes a credential's secret. Put in your credential's secret and the credential is revoked.

Here's an alternate scenario in which we allow unsigned requests. I think this would be much easier to implement.

Launchpadlib still requires a Credentials object, but the only required aspect of the Credentials object is the consumer name. Launchpadlib uses the consumer name as the User-Agent when making requests, possibly prefaced by 'launchpadlib:'.

When Launchpad gets an unsigned web service request, Launchpad pulls the consumer name out of User-Agent. If the consumer name is not registered with Launchpad as an OAuth consumer, Launchpad automatically registers it. (This maintains our ability to find out-of-control applications.) Launchpad then allows the request to go through as if it were signed with read-only public-only credentials.

Regardless of how we do this, a request not associated with any user will give different results than the same request with the same permissions but associated with a user. For instance, the "me_link" will either be None or the "me_link" key will not show up at all in the representation of the service root.

That unsigned request scenario sounds sane. But I can still just hack wadllib and launchpadlib to translate /beta URLs to /api/beta, and I work around all the auth/useragent stuff. Why require that at all?

Also, me_link points to /people/+me, and 401s when unauthenticated - that seems to be fine.

Because /api/beta is only for use by the Launchpad UI itself. We are not enforcing that at the moment but if usage spreads we will.

api.launchpad.net will support anonymous/unsigned request. (Only the User-Agent header will be used to identify the connecting app)

Retargetting to 2.2.8 as pointed by leonardr.

The thread starting at https://lists.launchpad.net/launchpad-dev/msg01019.html is related to this bug (and eventually mentions this bug).

OOI, why does the webapp require its own "private" API root? Is it just because browsers will only let you connect back to the originating domain, or is there anything deeper involved?

Is there any need to guard it against non-webapp access? Certainly it looks useful to me to allow people learning the basics of the API to pull up anonymous-read-only JSON documents in their web browser for inspection.

Yes, the browser's same-origin policy is why the webapp has its own API root. There's no problem with casually using the web service from your web browser. The thinking behind our desire for a detailed breakdown of non-browser clients is because their behavior is less predictable than browser clients. If you write a program that 100,000 people use and it turns out to have a huge bandwidth-sucking bug, we want to be able to throttle usage of that program.

2009/9/25 Leonard Richardson <email address hidden>:
> Yes, the browser's same-origin policy is why the webapp has its own API
> root. There's no problem with casually using the web service from your
> web browser. The thinking behind our desire for a detailed breakdown of
> non-browser clients is because their behavior is less predictable than
> browser clients. If you write a program that 100,000 people use and it
> turns out to have a huge bandwidth-sucking bug, we want to be able to
> throttle usage of that program.

Throttling usage of a particular program depends on that program
including a distinct user-agent-like string in its requests, which is
quite orthogonal to making all 100,000 people jump through a
registration hoop. If you care about this you would be better off
making the API documentation stress the importance of setting it
accurately.

--
Martin <http://launchpad.net/~mbp/>

Agreed. Please combine that comment with this comment:

https://bugs.edge.launchpad.net/launchpad-foundations/+bug/385517/comments/4

Fixed in devel r10102 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/10102>

way to go!

We should update the docs - does that need a separate bug?

Sorry about the confusion, my script moved this bug wrongly to fix released. It's fix committed and should be released in the 10.01 release.