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
Disease Control
655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada
From: John Chilton [jmchil...@gmail.com]
Sent: Wednesday, November 19, 2014 6:39 AM
To: Dooley, Damion
Cc: galaxy-dev@lists.bx.psu.edu
Subject: Re: [galaxy-dev] master_api_key currently doesn't benefit from a real
admin's key?!
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.
-John
On Tue, Nov 18, 2014 at 8:35 PM, Dooley, Damion damion.doo...@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 needed for.
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.
Thoughts?
Damion
___
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
