Thanks for the detailed description - this gives me a better
understanding of what is going on. Okay - I think the right way to
handle this is probably to make the master api key work everywhere
where the user API key is insufficient.
It makes sense to me that the master API key for instance cannot
import a workflow - that operation requires a user. But something like
creating a data library and assigning user roles to it or installing
tool shed repositories - should be doable via the master API. I
understand that it probably cannot do these specific things - but lets
call that a bug or at least a deficiency and modify the permission
checking to allow the master API key to do these things.
I like the idea of cleaning up the permissions better than attaching a
fake or arbitrary user object to the session in the abstract - though
it may prove more difficult in some cases. Do you want to try to
attempt this and open a pull request - it may be as simple as
modifying a few if checks to see if trans.user_is_admin() before doing
other more elaborate checks? Even if the fixes are too complicated
even just outlining the API endpoints you want to be able to use with
the master_api_key, a bioblend script to exercise them, and the Galaxy
stack traces would allow me or another devteam member to modify the
checks much more quickly.
Hope this helps,
On Wed, Nov 19, 2014 at 12:14 PM, Dooley, Damion <Damion.Dooley(a)bccdc.ca> wrote:
Ah! Key idea is the ease of installation/maintenance of tools that
need admin level api access.
I was hoping that the master api key enabled my program to do any of the api calls
available (I'm using bioblend btw). I am running workflows, uploading datasets from
user history to data library, linking files into data library from server. Alot of this
work is done on behalf of a user - but I don't want to give such a user elevated
access to the server. So yes I can hard-code an admin api key into my galaxy tool for
doing this work.
But I would much rather just count on a master/admin/uber api key that is defined in
galaxy config for doing all this work. This way, whenever a tool is installed from
toolshed that needs admin functionality, it can just start working if the "uber"
api key has been set up. (No need to set up an admin user, copy key into config or
wherever, reset galaxy etc). That's what I was thinking the "master" api
key did - I didn't realize it doesn't work with at least a handful of the API
calls because it lacks an associated user object. i had tried to put an admin api key
into the master_api_key field but that failed on various needed api calls - it ignores the
potential to use the admin user's user object.
By the way I do use the interacting user's non-privileged api key as well, it is
convenient for delineating what that user does and does not have access to in terms of
data libraries/datasets and workflows. Its just the extra work I trigger on their behalf
has to be admin level.
The tool itself is called the Data Versioning tool, and it is listing and
caching/retrieving versioned fasta (or other types of) data and regenerating blast etc.
databases as requested by users as an initial step to performing their other workflows.
It aims to quickly deal with datasets that are anywhere from megabytes to hundreds of
gigabytes in size.
Hope that helps?
Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre for
655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada
From: John Chilton [jmchilton(a)gmail.com]
Sent: Wednesday, November 19, 2014 6:39 AM
To: Dooley, Damion
Subject: Re: [galaxy-dev] master_api_key currently doesn't benefit from a real
If you already have an admin key in the database - that is more useful
than the master_api_key - I don't believe there is anything that the
master API key can do that the admin API key cannot (let me know if I
am wrong). I created master_api_key mostly just to bootstrap users and
API keys for new installations. So my question is what are you trying
to accomplish with a master API key if you already have an admin API
key? I would be happy to comment on the different ideas you mentioned
- but I want to understand what you are trying to accomplish.
On Tue, Nov 18, 2014 at 8:35 PM, Dooley, Damion <Damion.Dooley(a)bccdc.ca> wrote:
> I made the erroneous assumption that if I put my own admin user API key into the
galaxy configuration master_api_key field, it would accept that and run all the api
functions that needed a key connected to a user. It took fair bit of debugging to realize
that the master_api_key field chops off all the user info even if it is available (i.e.
has no user object), thus yielding numerous API errors for those things a user object is
> I can see a few dev solutions to this dilemma, and am wondering what people think -
and the result could get into a Trello feature card...
> a) allow master_api_key to be accompanied by a master_api_email; together they
trigger a user object to be associated that has the email address; and this eliminates all
the API errors one currently gets. I like this solution because it doesn't depend on
the UI interface for managing user keys, i.e. its rather permanent and secure.
> b) allow a api key called "admin_api_key" to be placed in the galaxy config
file. This key has to be active as one user's api key (presumably power user), so
that all those api errors are avoided.
> c) have master_api_key just have a dummy user object included, with say
admin@localhost for an email address.
> 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: