Hi Mohamed,
The problem with this solution is that the password again becomes part of the history since it is one of the inputs to the tool. If I want to publish this workflow then the password can’t be visible. For this reason password storage needs to be outside of workflows and handled somewhere else in Galaxy.
Steve
—Department of Computing, Macquarie University
http://web.science.mq.edu.au/~cassidy
On 28 Jul 2016, at 6:04 PM, Mohamed Kassam <k.mamoud@gmail.com> wrote:
Hi Steve,there is another solution is that the user is giving his credential via the tool. The only thing is missing the tag password on the xml then you can encrypt the password.I tried to add the new paramter on the build.py but I have some errors, don't know if someone arrived to fixed it.
Mohamed
2016-07-28 10:00 GMT+02:00 Steve Cassidy <steve.cassidy@mq.edu.au>:
Hi Mohamed,In my case, the credentials on Galaxy are not generally the same as on the remote system so we need some way to store a second set of credentials in the galaxy session.
So, for example, user Fred has an account on Galaxy (fred@here.com) and wants to get data from Alveo as input to a workflow. For the Alveo tools to get data, they need Fred’s access token from Alveo which Fred can retrieve by logging in to the Alveo website. Fred enters the access key into his preferences in Galaxy. This key is then passed to one or more tools that access Alveo on his behalf:
- the query tool finds words matching a given pattern from a spoken corpus (needs the token)- the get-data tool retrieves the audio files for each word (needs the token)- the automatic alignment tool finds the locations of the vowel sounds in each word- the annotation storer tool sends these locations back to Alveo as a new annotation set (needs the token)
and so on, at various times in the workflow, the tools need to talk to the repository to query, get data or add new data.
At the moment, I need the token to be a data item in the history, but it would be better if it were part of the user session in Galaxy.
Steve
—Department of Computing, Macquarie University
http://web.science.mq.edu.au/~cassidy
On 28 Jul 2016, at 5:46 PM, Mohamed Kassam <k.mamoud@gmail.com> wrote:
Hello Cassidy,I have the same problem like you because I need the user credential to access to an external tools.I tried the user session variables available in the toolxml file: __user__, __user_email__, __user_name__ and __user_id__. I t works perfectly I don't know if you need the password, because this is the only information is missing.
Mohamed
2016-07-28 9:42 GMT+02:00 Steve Cassidy <steve.cassidy@mq.edu.au>:
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
> On 28 Jul 2016, at 5:23 PM, Björn Grüning <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> 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>
>>
>>
>>
>> ___________________________________________________________
>> 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/
___________________________________________________________
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/