On 17 Oct. 2016, at 5:41 pm, Björn Grüning <bjoern.gruening@gmail.com> wrote:
Hi Steve and Katherine,
we are working on this branch and it is working:
https://github.com/bgruening/galaxy/tree/extra_user_preferences
But are a little bit sidetracked by porting the user-preferences from
mako to JS before we can include this into Main Galaxy, but the main
idea should work for tools and all other features we have in mind.
Cheers,
Bjoern
Am 17.10.2016 um 23:31 schrieb Katherine Beaulieu:
Ah I see, we had a similar problem except our service used a password
and username so we ended up implementing a password parameter that
didn't persist in the database.
On Mon, Oct 17, 2016 at 5:29 PM, Steve Cassidy <steve.cassidy@mq.edu.au
<mailto:steve.cassidy@mq.edu.au>> wrote:
Thanks Katherine, in my case I want to store the API key for an
external service (not Galaxy) and get access to that from a tool so
that the tool can act on behalf of the user.
Steve
—
Department of Computing, Macquarie University
http://web.science.mq.edu.au/~cassidy
<http://web.science.mq.edu.au/%7Ecassidy>
On 17 Oct. 2016, at 5:26 pm, Katherine Beaulieu
<katherine.beaulieu014@gmail.com
<mailto:katherine.beaulieu014@gmail.com>> wrote:
Hi Steve,
In terms of accessing the user's api key within a tool definition
file, have a look at this thread I had started. John had suggested
something but I haven't gotten it to work but maybe you will have
more luck than me.
http://dev.list.galaxyproject.org/Workflow-ID-Galaxy-Instance-URL-API-Key-in-Galaxy-Tool-Config-td4669906.html#a4670104
<http://dev.list.galaxyproject.org/Workflow-ID-Galaxy-Instance-URL-API-Key-in-Galaxy-Tool-Config-td4669906.html#a4670104>
Cheers,
Katherine
On Mon, Oct 17, 2016 at 5:17 PM, Steve Cassidy
<steve.cassidy@mq.edu.au <mailto:steve.cassidy@mq.edu.au>> wrote:
Hi Bjoern,
just wanting to revisit this question and perhaps get an
update on what you were doing for extending the user profile.
I just noticed in the galaxy sources the option to add ‘forms’
to be filled out at registration time. The admin interface
seems to allow me to create a form but it doesn’t appear when
I try to register. The code for this seems to be 2-5 years
old so perhaps it’s a forgotten corner?
https://github.com/galaxyproject/galaxy/tree/dev/templates/admin/forms
<https://github.com/galaxyproject/galaxy/tree/dev/templates/admin/forms>
Anyway, if you have made any progress on this I’d be happy to
hear about it. I’d like to be able to store the user’s API
key in the profile and access it from a tool definition file.
Cheers,
Steve
—
Department of Computing, Macquarie University
http://web.science.mq.edu.au/~cassidy
<http://web.science.mq.edu.au/%7Ecassidy>
On 28 Jul. 2016, at 2:59 pm, Björn Grüning
<bjoern.gruening@gmail.com
<mailto:bjoern.gruening@gmail.com>> wrote:
Hi Steve & Mohammed,
I'm working on a user-profile extension to get credentials
for a user,
but this will take a few more weeks sorry.
In the meantime can you look at the following idea:
my_programm.py --credentials $USER_CREDENTIALS --arguments
The variable $USER_CREDENTIALS is set during job execution
with dynamic
destination mappings
https://wiki.galaxyproject.org/Admin/Config/Jobs#Dynamic_Destination_Mapping
<https://wiki.galaxyproject.org/Admin/Config/Jobs#Dynamic_Destination_Mapping>
What do you think, would this work for you?
This assumes you as admin can pass along the user credentials
if you
know the username.
If not please get in touch and I will tell you about my plans
to extend
the user-preferences maybe you can help me with this to speed
things up.
Ciao,
Bjoern
Hi Bjorn,
sure, I don’t want to have the credentials stored in the
tool but the tool
needs to act on behalf of the user to retrieve data from the
repository, so
it needs access to credentials. This could for example be a
token generated
via an OAuth2 exchange - basically something that is sent
along with every
http request to the remote resource to authenticate the user.
My thought is that this could be stored in the user profile
if this can be made
available to the tool in the same way that __user_email__ is
now.
When you say ‘on the framework level’ do you mean by Galaxy?
Steve
—
Department of Computing, Macquarie University
http://web.science.mq.edu.au/~cassidy
<http://web.science.mq.edu.au/%7Ecassidy>
On 28 Jul 2016, at 5:23 PM, Björn Grüning
<bjoern.gruening@gmail.com
<mailto:bjoern.gruening@gmail.com>> wrote:
Hi Steve,
can you explain the larger use-case behind it. Imho you
should not
populate a tool with credentials, this should be handled on the
framework level.
Hope you are fine,
Bjoern
Am 28.07.2016 um 03:15 schrieb Steve Cassidy:
Hi again,
I’m looking for the right way to store some user
credentials in the
galaxy session so that tools can work on behalf of the
user with our
repository.
Currently users have an API key and they need to upload it
as a data
item to that is then passed to each tool that needs it as
input. This
doesn’t seem like the right solution since the API key
becomes part of
the history and so would be shared if the history were
shared.
What would be better would be a way of storing the API key
in the user
session and then being able to pass that into a tool.
I note that there are a few user session variables
available in the tool
xml file: __user__, __user_email__, __user_name__ and
__user_id__.
There is also a user preferences page where they can fill
out a few
details. However, I can’t see a mechanism to extend this
in any way and
have extra properties in the preferences pane that would
then be
available to tools via the template file.
I can see that the standard practice for the data sources on
usegalaxy.org <http://usegalaxy.org/>
<http://usegalaxy.org <http://usegalaxy.org/>> is to send
the user off to a
repository website to find data that is then posted back
to the galaxy
server. This isn’t appropriate for us since the
interaction with the
repository is not just for downloading a single dataset -
tools will
query the repository, download various kinds of data and
possibly upload
new data, so we need to store user credentials in some way.
Is there already a good way to achieve this or is this an
enhancement to
Galaxy?
Thanks,
Steve
—
Department of Computing, Macquarie University
http://web.science.mq.edu.au/~cassidy
<http://web.science.mq.edu.au/%7Ecassidy>
<http://web.science.mq.edu.au/%7Ecassidy
<http://web.science.mq.edu.au/%7Ecassidy>>
___________________________________________________________
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:
https://lists.galaxyproject.org/
<https://lists.galaxyproject.org/>
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
<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:
https://lists.galaxyproject.org/
<https://lists.galaxyproject.org/>
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
<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:
https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/