Dashboard API authentication issues
michael.hudson at canonical.com
Thu Oct 14 02:19:29 UTC 2010
On Tue, 12 Oct 2010 20:36:26 +0200, Zygmunt Krynicki <zygmunt.krynicki at linaro.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> As you know we've been trying to deliver an authenticated interface for
> the dashboard for quite some time now without success. Recently we've
> decided to add oauth support to the current XML-RPC interface we have.
> James implemented a rough support for this here  but it's not clear
> that we should accept this work yet. To quote James there are some
> issues with it today:
> 1. This relies on an external project that is unpackaged at this time.
> 2. That external project ships a patched embedded copy of python-oauth,
> though I don't know what the patches are for.
> 3. That project requires consumers to be pre-registered, and I'm not
> sure we want that. It would be possible to work around it, but would
> require some work.
> 4. I'm not sure I have the Resource stuff correct in this branch.
> 5. I'm not convinced that I have thought through all the corners and so
> there may be security holes.
> 6. There is nothing so far for the view to know if the request is oauth,
> which consumer it is etc., and no support for differing token access
> levels. We won't need any of that right away, but if we want that then
> django-piston may be the way to go rather than adding all of that.
It has to be said, I'm not sure the aesthetic appeal of oauth outweigh
these costs. It smells a bit overengineered.
> All in all those issues make me think that it's not as easy as we
> assumed and we should pursue another path. Before we do that let's
> summarize our current needs and priorities:
> 1) We need to allow users to authenticate before we allow them to upload
> test results (bundles) to certain directories (bundle streams) in a
> simple and efficient manner (client side code matters)
Is this all we want? As salgado asked in another mail, where is this
> 2) Currently our only client is abrek
Is this going to change?
> 3) We'd like to offer this very quickly, definitely before the UDS
I don't think we should allow time pressures to force us into a bad
decision. That said, I'm not sure the decision being made here is
necessarily that bad to get "wrong" at this stage.
> Having said that let's look at the options we have:
> A) Continue hacking oauth in good faith that it'll work as intended
> without falling apart/being insecure/being hard to deploy/missing deadlines.
I think the tone of your voice suggests you don't like this plan :-)
> B) Fall back to one of the B-plans:
> B1) use something other than oauth (like HTTP digest authentication)
This seems vaguely sane to me.
> B2) use something entirely different like:
> B2.1) django-piston
> B2.2) lazr.restful
> B2.1 (piston) cannot directly replace our current API as it does not
> support named methods (it only has CREATE/READ/UPDATE/DELETE). The
> upsides are that is seems to support oauth out of the box. The downside
> is that it's not packaged (at least properly on lucid which we target).
> We'd also have to pick a client-side library to use (lazr.resful most
> likely but I'm not sure really). We're also not sure if they work
> together out of the box.
> B2.2 (lazr-restful) might work but I don't know anything about it.
> Some other points to consider:
> 1) Offspring nee lexbuilder also has an XML-RPC interface (cody, please
> correct me if I'm wrong) and we should align the technology if
I don't really see the value in this, tbh.
> 2) We're not sure if we need full API but we're not sure that we don't
> need it either. Currently our _only_ requirement is to "allow people to
> submit test results" in whatever means necessary.
Right, so I think there is some value in keeping things simple until we
understand what our requirements are going to be.
> 3) Having looked at various "web APIs" it seems that passing an API key
> is a common practice. While not as fancy as oauth perhaps we should
> consider this.
This seems kinda ugly to me. OAuth is the wait to get this approach
right, isn't it?
> Having said that I'd like to propose my opinion:
> 1) Postpone oauth for UDS milestone (7 days left)
> 2) Work on alternative scheme that can be integrated with abrek easily
> in time for release
> 3) Continue on oauth path in a longer cycle (while retaining current
Given that UDS is so soon, is there much value on working on it
furiously before UDS, where the real requirements might become clear?
Having authentication doesn't seem a requirement for doing demos at the
summit to me.
More information about the linaro-dev