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?
Also, why encrypt the dataset/library/folder ids when a simple display is enough to get them?
Thanks L-A
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.
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.
--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:
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:
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:
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:
galaxy-dev@lists.galaxyproject.org
-
Louise-Amélie Schmitt -
Nate Coraor