[openspending-dev] api key

[Alberto Rodriguez Peon]

Hi!

So, to sum up:

I have a prototype version of the API to load a dataset, which right now uses three different parameters, the JSON file with the metadata, the actual CSV file and the api key of the creator (which has to be changed as exposing it can compromise the user).

It works in the same way as the ostool command does.

Personally, I think the approach with the public/private key will be the easiest (and fastest) to implement. The main problem is that I have only three weeks and a half left in my internship (and plenty of work to do in the CERN side too!). I think that it is not enough time to implement OAuth.

Cheers,
Alberto

________________________________
From: Tryggvi Björgvinsson [tryggvi.bjorgvinsson at okfn.org]
Sent: 19 August 2013 11:30
To: Stefan Wehrmeyer
Cc: Alberto Rodriguez Peon; openspending-dev at lists.okfn.org
Subject: Re: [openspending-dev] api key

On mán 19.ágú 2013 08:53, Stefan Wehrmeyer wrote:

you are right with your security concerncs. Since most developers only need read access (which doesn't need the key), this wasn't considered before.

Yes. The current setup only looks at a http header with the api key. No secret, no signature. This is probably because of the reason Stefan mentions.


We should strongly consider putting up SSL for OpenSpending (shouldn't be too hard, won't touch code base).

I agree. I've created a new issue for this:
https://github.com/openspending/openspending/issues/672


The possibility to regenerate an API key might also make sense.

Yes. That's a great idea! I've also created an issue for this:
https://github.com/openspending/openspending/issues/673


I would vote against a public/private key system as it will make OpenSpending more complex than necessary.

I'm not sure about that. I vote _for_ anything that makes our system more secure. I would suggest we support OAuth 2 which is reasonably well known so it won't make things more complex imo. There should be plenty of existing modules we could use.

Is this something you'd be interested in developing Alberto? You could go for both the solution you provided or OAuth (or something else -- implementor gets to choose).

--

Tryggvi Björgvinsson

Technical Lead, OpenSpending

The Open Knowledge Foundation<http://okfn.org>

Empowering through Open Knowledge

http://okfn.org/ | @okfn<http://twitter.com/OKFN> | OKF on Facebook<https://facebook.com/OKFNetwork> | Blog<http://blog.okfn.org/> | Newsletter<http://okfn.org/about/newsletter>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/openspending-dev/attachments/20130819/78bf7ffd/attachment.html>