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
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?
Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre for
655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada
From: John Chilton [jmchil...@gmail.com]
Sent: Thursday, October 02, 2014 9:42 AM
To: Dooley, Damion
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 -
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:
To search Galaxy mailing lists use the unified search at: