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?
Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre for Disease
655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada
From: John Chilton [jmchilton(a)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 -