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.orghttp://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
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/
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/
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 tool xml 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/
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.commailto: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.commailto: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 tool xml 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.aumailto: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.commailto: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.orghttp://usegalaxy.org/ <http://usegalaxy.orghttp://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/
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 tool xml 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/
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.commailto: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.aumailto: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.commailto: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.commailto: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 tool xml 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.aumailto: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.commailto: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.orghttp://usegalaxy.org/ <http://usegalaxy.orghttp://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/
Hi Steve so what you can do create a web authentification tool with Galaxy and bring back the information as it is done with the ucsc genopme browser. Maybe it should work, then you don't need to show the password in the history .
Mohamed
2016-07-28 10:17 GMT+02:00 Steve Cassidy steve.cassidy@mq.edu.au:
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 tool xml 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/
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
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
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/
Hey Björn,
I talked a bit about this with Katherine today, her group is quite interested in working on this as well.
I know we had discussed this a bit at GCC, and I posted a message today, outlining my plans which were formulated when I was at PSU the other month. Were those suggestions compatible with the existing work you'd done on generic KV store stuff?
Cheers, Eric
On 28. juli 2016 18:59, Björn Grüning 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
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
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/
Hi Eric,
I think they are. What you described is more the user-facing part. My current proof-of-concept does not have a tool-user-interface, it just stores the credentials in the framework and makes it accessible through the user-object. Which should be enough for dynamic job destinations. A dedicated user-interface for tools is a nice idea and we can put this ontop I think very easily!
Thanks for sharing! Bjoern
Am 28.07.2016 um 21:09 schrieb Eric Rasche:
Hey Björn,
I talked a bit about this with Katherine today, her group is quite interested in working on this as well.
I know we had discussed this a bit at GCC, and I posted a message today, outlining my plans which were formulated when I was at PSU the other month. Were those suggestions compatible with the existing work you'd done on generic KV store stuff?
Cheers, Eric
On 28. juli 2016 18:59, Björn Grüning 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
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
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/
--
Eric Rasche Programmer II
Center for Phage Technology Rm 312A, BioBio Texas A&M University College Station, TX 77843 404-692-2048 tel:404-692-2048 esr@tamu.edu mailto:esr@tamu.edu Not responding quickly enough? https://calendar.google.com/calendar/embed?src=esr%40tamu.edu&ctz=America/Chicago
Dear Bjoern, I think it should work for me.
I will contatct you to see how it can work for my purpose.
Thank you in advance,
Mohamed
2016-07-28 20:59 GMT+02:00 Björn Grüning bjoern.gruening@gmail.com:
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
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
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/
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
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
On 28 Jul. 2016, at 2:59 pm, Björn Grüning <bjoern.gruening@gmail.commailto: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
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
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/
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... Cheers, Katherine
On Mon, Oct 17, 2016 at 5:17 PM, Steve Cassidy 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
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
On 28 Jul. 2016, at 2:59 pm, Björn Grüning 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
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
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/
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
On 17 Oct. 2016, at 5:26 pm, Katherine Beaulieu <katherine.beaulieu014@gmail.commailto: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... Cheers, Katherine
On Mon, Oct 17, 2016 at 5:17 PM, Steve Cassidy <steve.cassidy@mq.edu.aumailto: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
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
On 28 Jul. 2016, at 2:59 pm, Björn Grüning <bjoern.gruening@gmail.commailto: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
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
On 28 Jul 2016, at 5:23 PM, Björn Grüning <bjoern.gruening@gmail.commailto: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.orghttp://usegalaxy.org/ <http://usegalaxy.orghttp://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/
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 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
On 17 Oct. 2016, at 5:26 pm, Katherine Beaulieu < 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 Cheers, Katherine
On Mon, Oct 17, 2016 at 5:17 PM, Steve Cassidy 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
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
On 28 Jul. 2016, at 2:59 pm, Björn Grüning 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_Des tination_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
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/
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, BjoernHi 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/
Thanks Bjoern, look forward to seeing this, happy to test it when it’s ready.
Steve
— Department of Computing, Macquarie University http://web.science.mq.edu.au/~cassidy
On 17 Oct. 2016, at 5:41 pm, Björn Grüning <bjoern.gruening@gmail.commailto: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.aumailto: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.commailto: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... 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.aumailto: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.commailto: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.commailto: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.orghttp://usegalaxy.org/ http://usegalaxy.org/ <http://usegalaxy.orghttp://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/
galaxy-dev@lists.galaxyproject.org
-
Björn Grüning -
Eric Rasche -
Katherine Beaulieu -
Mohamed Kassam -
Steve Cassidy