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 Control 655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada ________________________________________ From: John Chilton [email@example.com] Sent: Thursday, October 02, 2014 9:42 AM To: Dooley, Damion Cc: firstname.lastname@example.org 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 -