Simple standard for API use of a global user/key that all loaded tools can draw upon?
Do any of you see the need to establish a way for tools to use a global (current site) API url/key combination? From a security perspective I'm assuming this is basically ok since tools run under the galaxy user anyways (and can directly read and write files to their heart's content). I understand that a particular user's API key could help limit what they have access to. My tool however wants to do some prepatory form display and post-job work on behalf of the Galaxy system in addition to working with user-centric data; I presume others have similar use-case needs. I think it would amount to having a standard GALAXY_TOOL_API_URL and GALAXY_TOOL_API_KEY managed in universe_wsgi.ini (left blank if not desired by sys admin). The key would be generated by a galaxy admin using a real admin user id. These would be available as python or shell environment variables when it came time to execute a tool's <command interpreter="python"> etc. work. The wee other detail is that I'm using <code file="versioned_data_form.py" /> in my tool xml because there is API information I have to retrieve to set up the form with. So the url and key need to be accessible in that execution environment too?!! Am I missing the boat; alternately has this already been talked about?! Thanks for advice ... Damion Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre for Disease Control 655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada
I don't know about a standard way of doing - I am not sure about Galaxy officially supporting this but you can add whatever properties you want in universe_wsgi.ini (which will be renamed config/galaxy.ini in coming release). These can be accessed within tool cheetah blocks as $__app__.config.config_dict['name_of_property']. So we can define some unofficial standards for what to populate there such as galaxy_tool_api_url and galaxy_tool_api_key. In terms of the keys - there are some other things to be aware of. It is now possible to define a user-less master key in the config file. This would be accessible to tools as $__app__.config.master_api_key. It may be worth considering using that instead of grabbing a new key (some operations require a user though - so this master api key isn't a silver bullet). Also as of the last release there is a standard way to access keys from within Galaxy for users that *MAY* work within tool cheetah blocks. I haven't tested it bu my guess would be you do something like: #from galaxy.managers import api_keys# command --opt1=foo --api_key="${api_keys.ApiKeyManager( $__app__ ).get_or_create_api_key( $__user__ )}" (But that is unofficial and I haven't tried it myself.) Hope these random thoughts help somewhat. -John On Thu, Sep 25, 2014 at 3:18 PM, Dooley, Damion <Damion.Dooley@bccdc.ca> wrote:
Do any of you see the need to establish a way for tools to use a global (current site) API url/key combination? From a security perspective I'm assuming this is basically ok since tools run under the galaxy user anyways (and can directly read and write files to their heart's content). I understand that a particular user's API key could help limit what they have access to. My tool however wants to do some prepatory form display and post-job work on behalf of the Galaxy system in addition to working with user-centric data; I presume others have similar use-case needs.
I think it would amount to having a standard GALAXY_TOOL_API_URL and GALAXY_TOOL_API_KEY managed in universe_wsgi.ini (left blank if not desired by sys admin). The key would be generated by a galaxy admin using a real admin user id. These would be available as python or shell environment variables when it came time to execute a tool's <command interpreter="python"> etc. work.
The wee other detail is that I'm using <code file="versioned_data_form.py" /> in my tool xml because there is API information I have to retrieve to set up the form with. So the url and key need to be accessible in that execution environment too?!!
Am I missing the boat; alternately has this already been talked about?!
Thanks for advice ...
Damion
Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre for Disease Control 655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada ___________________________________________________________ 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/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Okay - revisiting this because I was not nearly cautious enough with my previous response. A couple large caveats - - Exposing the master key or any admin key on the command line will make it available to everyone who has access to the tools- so if you do so you either need to encode it some way, not pass it via the command line (the tool configfiles construct could be used), or trust your users. (Thanks to Nate for pointing that out.) - I wasn't intending to encourage you to use the trick I had for generating user API keys - only to let you know it may be possible. I just wanted to make that clear. Put another way it doesn't represent part of Galaxy's public API. But I now do have permission to expose a consistent interface to tool author's for communicating with the API - this is a frequent request from tool authors and I think it would help other projects such as the Galaxy IPython project. I have created a Trello card for this request here https://trello.com/c/hL4NYsSp (it is not exactly what you requested - it is more my distillation of several different requests I have heard over the years - please comment on the card if it doesn't quite fit what you would intend to do). Thanks. -John On Wed, Oct 1, 2014 at 1:26 PM, John Chilton <jmchilton@gmail.com> wrote:
I don't know about a standard way of doing - I am not sure about Galaxy officially supporting this but you can add whatever properties you want in universe_wsgi.ini (which will be renamed config/galaxy.ini in coming release). These can be accessed within tool cheetah blocks as $__app__.config.config_dict['name_of_property']. So we can define some unofficial standards for what to populate there such as galaxy_tool_api_url and galaxy_tool_api_key.
In terms of the keys - there are some other things to be aware of. It is now possible to define a user-less master key in the config file. This would be accessible to tools as $__app__.config.master_api_key. It may be worth considering using that instead of grabbing a new key (some operations require a user though - so this master api key isn't a silver bullet). Also as of the last release there is a standard way to access keys from within Galaxy for users that *MAY* work within tool cheetah blocks.
I haven't tested it bu my guess would be you do something like:
#from galaxy.managers import api_keys# command --opt1=foo --api_key="${api_keys.ApiKeyManager( $__app__ ).get_or_create_api_key( $__user__ )}"
(But that is unofficial and I haven't tried it myself.)
Hope these random thoughts help somewhat.
-John
On Thu, Sep 25, 2014 at 3:18 PM, Dooley, Damion <Damion.Dooley@bccdc.ca> wrote:
Do any of you see the need to establish a way for tools to use a global (current site) API url/key combination? From a security perspective I'm assuming this is basically ok since tools run under the galaxy user anyways (and can directly read and write files to their heart's content). I understand that a particular user's API key could help limit what they have access to. My tool however wants to do some prepatory form display and post-job work on behalf of the Galaxy system in addition to working with user-centric data; I presume others have similar use-case needs.
I think it would amount to having a standard GALAXY_TOOL_API_URL and GALAXY_TOOL_API_KEY managed in universe_wsgi.ini (left blank if not desired by sys admin). The key would be generated by a galaxy admin using a real admin user id. These would be available as python or shell environment variables when it came time to execute a tool's <command interpreter="python"> etc. work.
The wee other detail is that I'm using <code file="versioned_data_form.py" /> in my tool xml because there is API information I have to retrieve to set up the form with. So the url and key need to be accessible in that execution environment too?!!
Am I missing the boat; alternately has this already been talked about?!
Thanks for advice ...
Damion
Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre for Disease Control 655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada ___________________________________________________________ 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/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Ok, thanks for the on-target info and organizing the Trello card solution. So the <configfiles> construct lets us pass data that is available in the cheeta template context into a temporary file which the tool then has access to, thus avoiding exposing parameters in the command line execution which are visible when any user clicks on the "i" info link in history. Sounds good for user-triggered tool case; I think this would work for my tool. I left this note on the trello card... "Optional good. A job specific key would be fine too, but it would need a powerful permission profile. John, I also see the security threat of passing the key to the command line un-encoded. Is it possible for the command executable program to have access to one in the executable environment as long as its being executed by a 'galaxy' system privileged user?" I think that approach would detail the minimum stand-alone command line python (etc) code that could be run by system galaxy user to lookup the __app__.config.master_api_key , or to generate a tool-session key. (It would fail for other system users). That would support API activity that isn't being called from the web interface and its cheeta templating system. E.g use case of crontab scheduled events? Cheers, d. Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre for Disease Control 655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada ________________________________________ From: John Chilton [jmchilton@gmail.com] Sent: Thursday, October 02, 2014 9:42 AM To: Dooley, Damion Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] Simple standard for API use of a global user/key that all loaded tools can draw upon? Okay - revisiting this because I was not nearly cautious enough with my previous response. A couple large caveats - ...
participants (2)
-
Dooley, Damion -
John Chilton