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.doo...@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/
___________________________________________________________
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/
