[atlas]Simple way to open API access?
Hey all, Suggestion for a simple way to provide some basic automated access to ATLAS data: It's pretty clear from the traffic that the site is driven off a set of JSON APIs [1]. This would make it pretty easy to write scripts that can access information from the site -- except that the script would need to have a Cookie for a valid user session. So it seems like a simple way to open access up would be to allow developers to access these JSON APIs, but with a different form of authentication. Namely, you could grant developers an "API key" that would function in the same way as a 'stat-session' cookie (in particular it would be bound to a developer identity/email), but would last indefinitely. This wouldn't really put any burden on the NCC other than to have a page to register the API keys. It would be helpful to document the APIs, but not strictly necessary, since JSON is so verbose. And you wouldn't necessarily have any additional requirements for the APIs to be stable, if this feature were properly marked as experimental/undocumented. Noting that the other cookie that the ATLAS page sets is "csrftoken" (which would probably have to be ignored in API key requests), it is worth noting that there is some risk with this approach that a bad developer will use this mechanism to enable CSRF attacks. But such attacks should be fairly easy to recognize, and if one is, then the relevant developer can be turned off. Just a thought, --Richard [1] For example <http://atlas.ripe.net/atlas/publicprobesgrid.json>
Hi, Virtually all client libraries know how to handl cookies. I believe that nothing is stopping you from authenticating your API client's session with your usual name/password using the login URL, and then use the authenticated cookie to fetch the data. Of course it's a two step process, but it's easily automated and has much better security properties. Robert On 2011.03.24. 15:51, Richard L. Barnes wrote:
Hey all,
Suggestion for a simple way to provide some basic automated access to ATLAS data:
It's pretty clear from the traffic that the site is driven off a set of JSON APIs [1]. This would make it pretty easy to write scripts that can access information from the site -- except that the script would need to have a Cookie for a valid user session.
So it seems like a simple way to open access up would be to allow developers to access these JSON APIs, but with a different form of authentication. Namely, you could grant developers an "API key" that would function in the same way as a 'stat-session' cookie (in particular it would be bound to a developer identity/email), but would last indefinitely.
This wouldn't really put any burden on the NCC other than to have a page to register the API keys. It would be helpful to document the APIs, but not strictly necessary, since JSON is so verbose. And you wouldn't necessarily have any additional requirements for the APIs to be stable, if this feature were properly marked as experimental/undocumented.
Noting that the other cookie that the ATLAS page sets is "csrftoken" (which would probably have to be ignored in API key requests), it is worth noting that there is some risk with this approach that a bad developer will use this mechanism to enable CSRF attacks. But such attacks should be fairly easy to recognize, and if one is, then the relevant developer can be turned off.
Just a thought, --Richard
[1] For example <http://atlas.ripe.net/atlas/publicprobesgrid.json>
That's true, but it has the irritation that the session cookies expire, in 24 hours IIRC. So if you want to run a script every few days, you have to manually reconfigure it -- or spoof the login page! --Richard On Mar 24, 2011, at 11:08 AM, Robert Kisteleki wrote:
Hi,
Virtually all client libraries know how to handl cookies. I believe that nothing is stopping you from authenticating your API client's session with your usual name/password using the login URL, and then use the authenticated cookie to fetch the data. Of course it's a two step process, but it's easily automated and has much better security properties.
Robert
On 2011.03.24. 15:51, Richard L. Barnes wrote:
Hey all,
Suggestion for a simple way to provide some basic automated access to ATLAS data:
It's pretty clear from the traffic that the site is driven off a set of JSON APIs [1]. This would make it pretty easy to write scripts that can access information from the site -- except that the script would need to have a Cookie for a valid user session.
So it seems like a simple way to open access up would be to allow developers to access these JSON APIs, but with a different form of authentication. Namely, you could grant developers an "API key" that would function in the same way as a 'stat-session' cookie (in particular it would be bound to a developer identity/email), but would last indefinitely.
This wouldn't really put any burden on the NCC other than to have a page to register the API keys. It would be helpful to document the APIs, but not strictly necessary, since JSON is so verbose. And you wouldn't necessarily have any additional requirements for the APIs to be stable, if this feature were properly marked as experimental/undocumented.
Noting that the other cookie that the ATLAS page sets is "csrftoken" (which would probably have to be ignored in API key requests), it is worth noting that there is some risk with this approach that a bad developer will use this mechanism to enable CSRF attacks. But such attacks should be fairly easy to recognize, and if one is, then the relevant developer can be turned off.
Just a thought, --Richard
[1] For example <http://atlas.ripe.net/atlas/publicprobesgrid.json>
Hi Richard, Thats pretty simple :) --------------------------------------------- import mechanize br = mechanize.Browser() br.open("https://atlas.ripe.net/atlas/login/") br.select_form(nr=1) br['username'] = 'rbarnes@bbn.com' br['password'] = '<your password>' br.submit() print br.open("https://atlas.ripe.net/atlas/publicprobesgrid.json").read() ---------------------------------------------- Regards /vty On 03/24/2011 04:18 PM, Richard L. Barnes wrote:
That's true, but it has the irritation that the session cookies expire, in 24 hours IIRC. So if you want to run a script every few days, you have to manually reconfigure it -- or spoof the login page!
--Richard
On Mar 24, 2011, at 11:08 AM, Robert Kisteleki wrote:
Hi,
Virtually all client libraries know how to handl cookies. I believe that nothing is stopping you from authenticating your API client's session with your usual name/password using the login URL, and then use the authenticated cookie to fetch the data. Of course it's a two step process, but it's easily automated and has much better security properties.
Robert
On 2011.03.24. 15:51, Richard L. Barnes wrote:
Hey all,
Suggestion for a simple way to provide some basic automated access to ATLAS data:
It's pretty clear from the traffic that the site is driven off a set of JSON APIs [1]. This would make it pretty easy to write scripts that can access information from the site -- except that the script would need to have a Cookie for a valid user session.
So it seems like a simple way to open access up would be to allow developers to access these JSON APIs, but with a different form of authentication. Namely, you could grant developers an "API key" that would function in the same way as a 'stat-session' cookie (in particular it would be bound to a developer identity/email), but would last indefinitely.
This wouldn't really put any burden on the NCC other than to have a page to register the API keys. It would be helpful to document the APIs, but not strictly necessary, since JSON is so verbose. And you wouldn't necessarily have any additional requirements for the APIs to be stable, if this feature were properly marked as experimental/undocumented.
Noting that the other cookie that the ATLAS page sets is "csrftoken" (which would probably have to be ignored in API key requests), it is worth noting that there is some risk with this approach that a bad developer will use this mechanism to enable CSRF attacks. But such attacks should be fairly easy to recognize, and if one is, then the relevant developer can be turned off.
Just a thought, --Richard
[1] For example<http://atlas.ripe.net/atlas/publicprobesgrid.json>
participants (3)
-
Richard L. Barnes -
Robert Kisteleki -
Viktor Naoumov