-----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
On Tue, 2010-10-12 at 20:36 +0200, Zygmunt Krynicki 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.
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)
Currently our only client is abrek
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
django-piston is a library to generate/expose a RESTFul API out of existing code, and it happens to have an OAuth implementation built in, so I don't think we should use that just for its OAuth implementation. And even if we decide to convert launch-control's API into a RESTFul one, I'm not sure django-piston is the right tool for the job, for the reason you mention below.
B2.2) lazr.restful
lazr.restful won't be of any help with supporting OAuth as it doesn't have an implementation of that built in.
lazr.authentication, though, is used by other django projects in Canonical to support OAuth.
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 2) We're not sure if we need full API but we're not sure that we don't
What do you mean by full API?
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.
I think we can use existing libraries (python-oauth and lazr.authentication) and follow the examples of Canonical django projects that support OAuth, to support OAuth on launch-control. However, given that the deadline is very close, the alternative you propose above might be acceptable if the API is served over HTTPS.
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).
Thanks ZK
[1] https://code.edge.launchpad.net/~james-w/launch-control/oauth/+merge/38013
[ Apologies to anyone receiving this again, but I have had problems with mail delivery and wanted to make sure that everyone got this ]
On Wed, 13 Oct 2010 12:35:54 -0300, Guilherme Salgado salgado@canonical.com wrote:
I think we can use existing libraries (python-oauth and lazr.authentication) and follow the examples of Canonical django projects that support OAuth, to support OAuth on launch-control. However, given that the deadline is very close, the alternative you propose above might be acceptable if the API is served over HTTPS.
lazr.authentication is fairly nice, but also fairly minimal. What is missing from the combination of python-oauth and lazr.authentication is the models for storing tokens etc. via the Django ORM.
We could extract those parts from canonical-identity-provider in to a new app, which would be of use to everyone that wants to do this.
What I like about the lazr.authentication solution is that it integrates with the Django auth system in that you just get a request.user that you can check as you like. Plain django-oauth and django-piston don't seem to have that, and I'd like to keep that separation of concerns if possible.
I think that given that most of the code for the lazr.authentication based solution already exists we could deliver something by Tuesday, but we still don't have an answer to the question of external dependencies.
Zygmunt, have you discussed that question with Spike? Does anyone else know what IS would prefer there?
Thanks,
James
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
W dniu 14.10.2010 04:19, Michael Hudson pisze:
It has to be said, I'm not sure the aesthetic appeal of oauth outweigh these costs. It smells a bit overengineered.
Alternatives?
- 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 that's the only thing we _require_. We will want more things but I'd like to solve one problem at a time.
- Currently our only client is abrek
Is this going to change?
Most likely it's going to grow to more programs. I'd like to ship an official client-side library that programs like abrek can use to be isolated from how we do stuff internally.
- 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.
While I agree I also value the act of shipping useful stuff even if we need to clean some bits up later on. Having said that, I don't think the "bad" scenario is that wrong either.
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 :-)
If I used oauth before and knew if like the back of my hand I'd be more optimistic here. My primary concern is that 1) we'll miss deadline 2) it's not going to be pretty on the client side 3) we'll get it wrong somewhere.
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.
If cody has to solve the same problem then we could at least share the solution later on.
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.
I think it solves an important aspect of having some sensibility to how we push our data. Currently anyone can push anything anywhere. That's just bad IMHO. It's not devastating but not something I'd like to give.
Regards ZK
-
Guilherme Salgado -
James Westby -
Michael Hudson -
Zygmunt Krynicki