Re: [galaxy-dev] API keys and id encryption (silly questions)
Le 29/08/2011 18:54, Nate Coraor a écrit : Louise-Amélie Schmitt wrote: Le 29/08/2011 15:52, Nate Coraor a écrit : Louise-Amélie Schmitt wrote: Hello everyone, These questions are a bit silly but I'm really ignorant when it comes to security. Sorry about that. Why use API keys instead of user names? Is it to to prevent anyone from figuring out who is behind an URL? Or did I miss the point? Hi L-A, To provide a username password, we'd either need to implement HTTP Authentication in Galaxy for these resources, or encode it in the URL. If in the URL, the password have to be non-plaintext which would require encoding on the user's end. The key model seemed to be simplest since it doesn't require you to handle HTTP Authentication in your client-side code. Ok, I actually missed the point, thanks! :D Also, why encrypt the dataset/library/folder ids when a simple display is enough to get them? Anywhere that the IDs are visible are remnants of old code and should eventually be removed. Sorry I meant the encrypted ids. Why encrypt them? is it to prevent any direct use of the database? There are a couple of reasons - the first is that since by default, data is public, we wanted to make it non-trivial to just run sequentially through IDs to view related data. The other is that some people may prefer that it not be obvious how many datasets/jobs/libraries/etc. there are on their server. Ok, thanks a lot for all this information! :) Best, L-A --nate Thanks, L-A --nate Thanks L-A ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] API keys and id encryption (silly questions)
Le 29/08/2011 15:52, Nate Coraor a écrit : Louise-Amélie Schmitt wrote: Hello everyone, These questions are a bit silly but I'm really ignorant when it comes to security. Sorry about that. Why use API keys instead of user names? Is it to to prevent anyone from figuring out who is behind an URL? Or did I miss the point? Hi L-A, To provide a username password, we'd either need to implement HTTP Authentication in Galaxy for these resources, or encode it in the URL. If in the URL, the password have to be non-plaintext which would require encoding on the user's end. The key model seemed to be simplest since it doesn't require you to handle HTTP Authentication in your client-side code. Ok, I actually missed the point, thanks! :D Also, why encrypt the dataset/library/folder ids when a simple display is enough to get them? Anywhere that the IDs are visible are remnants of old code and should eventually be removed. Sorry I meant the encrypted ids. Why encrypt them? is it to prevent any direct use of the database? Thanks, L-A --nate Thanks L-A ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] API keys and id encryption (silly questions)
Louise-Amélie Schmitt wrote: Le 29/08/2011 15:52, Nate Coraor a écrit : Louise-Amélie Schmitt wrote: Hello everyone, These questions are a bit silly but I'm really ignorant when it comes to security. Sorry about that. Why use API keys instead of user names? Is it to to prevent anyone from figuring out who is behind an URL? Or did I miss the point? Hi L-A, To provide a username password, we'd either need to implement HTTP Authentication in Galaxy for these resources, or encode it in the URL. If in the URL, the password have to be non-plaintext which would require encoding on the user's end. The key model seemed to be simplest since it doesn't require you to handle HTTP Authentication in your client-side code. Ok, I actually missed the point, thanks! :D Also, why encrypt the dataset/library/folder ids when a simple display is enough to get them? Anywhere that the IDs are visible are remnants of old code and should eventually be removed. Sorry I meant the encrypted ids. Why encrypt them? is it to prevent any direct use of the database? There are a couple of reasons - the first is that since by default, data is public, we wanted to make it non-trivial to just run sequentially through IDs to view related data. The other is that some people may prefer that it not be obvious how many datasets/jobs/libraries/etc. there are on their server. --nate Thanks, L-A --nate Thanks L-A ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
