On Tue, 12 Oct 2010 20:36:26 +0200, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi.
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 [1] but it's not clear that we should accept this work yet. To quote James there are some issues with it today:
- This relies on an external project that is unpackaged at this time.
- 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:
- 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 API going?
- Currently our only client is abrek
Is this going to change?
- 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:
- Offspring nee lexbuilder also has an XML-RPC interface (cody, please
correct me if I'm wrong) and we should align the technology if possible
I don't really see the value in this, tbh.
- 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.
- 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:
- Postpone oauth for UDS milestone (7 days left)
- 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 interface).
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.
Cheers, mwh