-----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: 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. 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) 2) Currently our only client is abrek 3) We'd like to offer this very quickly, definitely before the UDS 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. B) Fall back to one of the B-plans: B1) use something other than oauth (like HTTP digest authentication) 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 possible 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. 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. 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 interface). Thanks ZK [1] https://code.edge.launchpad.net/~james-w/launch-control/oauth/+merge/38013 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMtKqqAAoJEKkR4hQBRI+lRzAIAJGtprqkZqdbP7+bOLar2JNM N9Q1vWHcGfp7BLhG/Cvu30w5jBvyQ0+CKfVUbyBBE8Ig3v2/jbGfZRC5c4t38c0B 9WD7i6COk/KiMN2rPzv6PPgoLhiA7tpxhajNA/rzYQJU3HIDIe1O12rnC+xCBdfp FuzqeKISIuUBKGSI/TUdZx1z0PTIE9bEr+6Cr1es+6XRZvav+vkbIotIqJWJfxmj oxUbfYU92Q7VzxpxMuxZQz8a1DFMuckkIRT4Goh17WFXZYcFgr9jMLgKwiJWytos WIGQLZWJXo++GZC83585yGd2yMlzyP0iF0KocDPQtwPW9bZCVxyYMBK55PLUJw4= =OKuR -----END PGP SIGNATURE----- _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
