[galaxy-dev] Re: URL prefix doesn't work properly in Galaxy v18.09

2019-05-20 Thread Ping Luo
Peter,

Thanks for the fix. We will try it on our galaxy.

Best,

Ping

On Thu, May 16, 2019 at 9:01 AM Peter Briggs 
wrote:

> Replying to my own message in case it's of use to someone else:
>
> It looks like this can be fixed by commenting out the 'target:
> "__use_router__"' lines in client/galaxy/scripts/layout/menu.js i.e.
>
> diff --git a/client/galaxy/scripts/layout/menu.js
> b/client/galaxy/scripts/layout/menu.js
> index 2dc1b41098..2d4c1db8c7 100644
> --- a/client/galaxy/scripts/layout/menu.js
> +++ b/client/galaxy/scripts/layout/menu.js
> @@ -46,7 +46,8 @@ var Collection = Backbone.Collection.extend({
>  tooltip: _l("Chain tools into workflows"),
>  disabled: !Galaxy.user.id,
>  url: "workflows/list",
> -target: "__use_router__"
> +//PJB remove target as it seems to break when using
> proxy-prefix
> +//target: "__use_router__"
>  });
>
>  //
> @@ -61,7 +62,8 @@ var Collection = Backbone.Collection.extend({
>  {
>  title: _l("Create Visualization"),
>  url: "visualizations",
> -target: "__use_router__"
> +//PJB remove target as it seems to break when using
> proxy-prefix
> +//target: "__use_router__"
>  },
>  {
>  title: _l("Interactive Environments"),
>
> (I needed to recompile the packed Javascript afterwards by running the
> common_startup.sh script before the changes appeared in the web interface.)
>
> This appears to fix the links to "Workflows" and "Visualisations" in the
> masthead of the main page.
>
> HTH
>
> Best wishes
>
> Peter
>
> --
> Peter Briggs peter.bri...@manchester.ac.uk
> Bioinformatics Core Facility University of Manchester
> B.1083 Michael Smith Bldg Tel: (0161) 2751482
>
>
> 
> From: Peter Briggs [peter.bri...@manchester.ac.uk]
> Sent: Thursday, May 16, 2019 2:01 PM
> To: Ping Luo; galaxy-dev
> Subject: [galaxy-dev] Re: URL prefix doesn't work properly in Galaxy v18.09
>
> Hello Ping (and Galaxy-devs)
>
> Did this get resolved? We are still on 18.09 and serving our production
> instance with a proxy prefix, and one of my users has hit this issue when
> trying to access the "Workflows" tab from the main page.
>
> As Ping says, it appears that Galaxy is inserting an extra copy of the
> prefix into the target URL - if the user removes this manually then the
> page loads okay.
>
> Does anyone know, is there a fix for this in 18.09?
>
> Thanks!
>
> Peter
>
> --
> Peter Briggs peter.bri...@manchester.ac.uk
> Bioinformatics Core Facility University of Manchester
> B.1083 Michael Smith Bldg Tel: (0161) 2751482
>
> 
> From: galaxy-dev [galaxy-dev-boun...@lists.galaxyproject.org] on behalf
> of Ping Luo [luop0...@gmail.com]
> Sent: Monday, December 17, 2018 9:04 PM
> To: galaxy-dev
> Subject: [galaxy-dev] URL prefix doesn't work properly in Galaxy v18.09
>
> I configured URL prefix in galaxy 18.09. It has problems of resolving some
> of the links, including:
>
>  workflow
>  visualize -> create visualization
>  shared data -> workflows
>  shared data -> visualizations
>
> I will use workflow as an example to illustrate what happens. When the
> mouse cursor is put on workflow, the URL shown in at the left bottom of the
> browser shows
>
>  https://xxx.xxx.tamu.edu/galaxy/workflows/list
>
> But after I clicked 'workflow', the real URL shown in the address bar is
> actually
>
>
> https://xxx..tamu.edu/galaxy/galaxy//workflows/list?__identifer=sk0xsywiqrs
>
> Of course, there is no such a page and the browser shows a blank page. If
> I manually remove one galaxy in the URL, the page is correctly shown.
>
> Beside the four mentioned above, other links work fine. If galaxy is
> configured without prefix, then there is no problem.
>
>  I also tested v18.05. With all the configuration being the same, this
> version doesn't have the problem with prefix like v18.09 does. So I think
> this is a bug in v18.09 with URL prefix.
>
> Ping
> ___
> 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:
>   %(web_page_url)s
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/
>
___
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:
  %(web_page_url)s

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/


[galaxy-dev] URL prefix doesn't work properly in Galaxy v18.09

2018-12-17 Thread Ping Luo
I configured URL prefix in galaxy 18.09. It has problems of resolving some
of the links, including:

 workflow
 visualize -> create visualization
 shared data -> workflows
 shared data -> visualizations

I will use workflow as an example to illustrate what happens. When the
mouse cursor is put on workflow, the URL shown in at the left bottom of the
browser shows

 https://xxx.xxx.tamu.edu/galaxy/workflows/list

But after I clicked 'workflow', the real URL shown in the address bar is
actually


https://xxx..tamu.edu/galaxy/galaxy//workflows/list?__identifer=sk0xsywiqrs

Of course, there is no such a page and the browser shows a blank page. If I
manually remove one galaxy in the URL, the page is correctly shown.

Beside the four mentioned above, other links work fine. If galaxy is
configured without prefix, then there is no problem.

 I also tested v18.05. With all the configuration being the same, this
version doesn't have the problem with prefix like v18.09 does. So I think
this is a bug in v18.09 with URL prefix.

Ping
___
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/

Re: [galaxy-dev] how to configure sub-uri in galaxy.yml

2018-12-14 Thread Ping Luo
Peter,

I just figured out how to fix it. In galaxy.yml, I changed HTTP_REMOTE_USER
to REMOTE_USER, and now it works. My next thing is to test the sub-uri.

Thanks,

Ping

On Fri, Dec 14, 2018 at 11:02 AM Ping Luo  wrote:

> Peter,
>
> I have been using the default http protocol for the Galaxy server which is
> not preferred. I am now testing uwsgi TCP sockets. I start the server on
> server root without sub-uri to see how it works.
>
> Here is my Apache configuration:
>
> 
> ServerName  xxx.xxx.xxx.xxx
> ServerAdmin ad...@xxx.xxx
>
> DocumentRoot "/opt/rh/httpd24/root/var/www/html"
> TransferLog  "logs/scgalaxy_access.log"
> ErrorLog "logs/scgalaxy_error.log"
>
> SSLEngine On
> SSLProtocol  all -SSLv3 -TLSv1 -TLSv1.1
> SSLCertificateFile  "/etc/pki/tls/certs/galaxy.cer"
> SSLCertificateKeyFile   "/etc/pki/tls/private/galaxy.key"
> SSLCertificateChainFile "/etc/pki/tls/certs/galaxy.cer"
>
> RewriteEngine on
> ProxyPass /uwsgi://127.0.0.1:4001/ #
> access is denied due to username not provided with external authentication
> method
> #   ProxyPass /http://127.0.0.1:8080/   #
> same configuration works fine with http
>
> 
> SSLRequireSSL
> AuthType CAS
> Require valid-user
> RewriteCond %{IS_SUBREQ} ^false$
> RewriteCond %{LA-U:REMOTE_USER} (.+)
> RewriteRule . - [E=RU:%1]
> RequestHeader set X-URL-SCHEME https
> RequestHeader set REMOTE_USER  %{REMOTE_USER}s
> 
> 
>
> However, when accessing the galaxy server, I got the following error. The
> same setting works fine when galaxy is served with http. What need be
> changed in Apache for serving galaxy with uwsgi socket?
> Access to Galaxy is denied
>
> Galaxy is configured to authenticate users via an external method (such as
> HTTP authentication in Apache), but a username was not provided by the
> upstream (proxy) server. This is generally due to a misconfiguration in the
> upstream server.
>
>
> The log file dumps the following output:
>
> galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,724
> [p:19333,w:1,m:0] [uWSGIWorker1Core0] Unable to identify user.
> HTTP_REMOTE_USER not found
> galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,725
> [p:19333,w:1,m:0] [uWSGIWorker1Core0] wsgi.multiprocess = False
> galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,725
> [p:19333,w:1,m:0] [uWSGIWorker1Core0] paste.recursive.include_app_iter =
> 
> galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,725
> [p:19333,w:1,m:0] [uWSGIWorker1Core0] HTTP_COOKIE =
> _ga=GA1.2.525722961.1528376483;
> __utma=194481448.525722961.1528376483.1528377532.1528377532.1;
> _vwo_uuid_v2=DF9EBC570796316331B3F82AE49BE8DE8|18923f6303554ba0ab6938b046ebc11c;
> _vwo_uuid=DF9EBC570796316331B3F82AE49BE8DE8;
> MOD_AUTH_CAS_S=4865a71d55619aa6196d7b753d27356e;
> galaxysession=4a833ad4d9934a58ce0b64778f963b982b8f5e10ca4a7b26ac9eeb1368c1462fdcb2aa7c9f32ba00
> galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,726
> [p:19333,w:1,m:0] [uWSGIWorker1Core0] paste.recursive.forward =
> 
> galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,726
> [p:19333,w:1,m:0] [uWSGIWorker1Core0] CONTEXT_DOCUMENT_ROOT =
> /opt/rh/httpd24/root/var/www/html
> galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,726
> [p:19333,w:1,m:0] [uWSGIWorker1Core0] SERVER_SOFTWARE = Apache/2.4.34 (Red
> Hat) OpenSSL/1.0.2k-fips Phusion_Passenger/4.0.50
> galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,726
> [p:19333,w:1,m:0] [uWSGIWorker1Core0] paste.recursive.include =
> 
> galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,726
> [p:19333,w:1,m:0] [uWSGIWorker1Core0] CONTEXT_PREFIX =
> galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,726
> [p:19333,w:1,m:0] [uWSGIWorker1Core0] SERVER_SIGNATURE =
> galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,726
> [p:19333,w:1,m:0] [uWSGIWorker1Core0] REQUEST_METHOD = GET
> galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,726
> [p:19333,w:1,m:0] [uWSGIWorker1Core0] PATH_INFO = /
> galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,726
> [p:19333,w:1,m:0] [uWSGIWorker1Core0] SERVER_PROTOCOL = HTTP/1.1
> galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,726
> [p:19333,w:1,m:0] [uWSGIWorker1Core0] QUERY_STRING =
> galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,727
> [p:193

Re: [galaxy-dev] how to configure sub-uri in galaxy.yml

2018-12-14 Thread Ping Luo
:19333,w:1,m:0] [uWSGIWorker1Core0] uwsgi.version = 2.0.17.1
galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,731
[p:19333,w:1,m:0] [uWSGIWorker1Core0] request_id =
d8e1b156ffc111e8bbbc0894ef20d911
galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,731
[p:19333,w:1,m:0] [uWSGIWorker1Core0] wsgi.file_wrapper = 
galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,732
[p:19333,w:1,m:0] [uWSGIWorker1Core0] HTTP_ACCEPT_ENCODING = gzip, deflate,
br
galaxy.web.framework.middleware.remoteuser DEBUG 2018-12-14 11:01:06,732
[p:19333,w:1,m:0] [uWSGIWorker1Core0] UNIQUE_ID =
XBPh0ilC82mF4py6Qa6eRwI


Thanks,


Ping

On Wed, Dec 12, 2018 at 5:07 AM Peter Briggs 
wrote:

> Hello Ping
>
> If you're using the YAML config then there isn't an equivalent of the
> "[filter:proxy-prefix]" section from the INI version of the config - this
> section doesn't seem to be required any more. So the two lines you already
> have in the 'galaxy' section of the YAML file should be sufficient i.e.
>
> galaxy:
> #...
> filter-with: proxy-prefix
> cookie_path: '/galaxy'
>
> However you also need to make sure that you have the correct options in
> the 'uwsgi' section of the YAML config file, and that your Apache
> configuration is set correctly to handle the proxy prefix. The relevant
> documentation for these is here (for 18.09):
>
>
> https://docs.galaxyproject.org/en/release_18.09/admin/apache.html#serving-galaxy-at-a-url-prefix
>
> HTH
>
> Best wishes
>
> Peter
>
> --
> Peter Briggs peter.bri...@manchester.ac.uk
> Bioinformatics Core Facility University of Manchester
> B.1083 Michael Smith Bldg Tel: (0161) 2751482
>
> --
> *From:* galaxy-dev [galaxy-dev-boun...@lists.galaxyproject.org] on behalf
> of Ping Luo [luop0...@gmail.com]
> *Sent:* Wednesday, December 12, 2018 6:35 AM
> *To:* galaxy-dev
> *Subject:* [galaxy-dev] how to configure sub-uri in galaxy.yml
>
> I am trying to configure Galaxy v18.09 wtih sub-uri. In prior 18.01, I use
> this configuration in conjunction with Apache rewrite rules and it works
> well:
>
> [filter:proxy-prefix]
> use = egg:PasteDeploy#prefix
> prefix = /msgalaxy
> [app:main]
> filter-with = proxy-prefix
> cookie_path = '/galaxy'
>
>
> In galaxy.yml, I know I need to uncomment and add the following
>
> filter-with: proxy-prefix
> cookie_path: '/galaxy'
>
> However, I don't know where and how to add filter:proxy-prefix. The
> comment in config.yml says:
>
>   # If running behind a proxy server and Galaxy is served from a
>   # subdirectory, enable the proxy-prefix filter and set the prefix in
>   # the [filter:proxy-prefix] section above.
>
> which is for galaxy.ini file. An example on how to do it would be much
> appreciated.
>
> Ping
>
___
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/

[galaxy-dev] how to configure sub-uri in galaxy.yml

2018-12-11 Thread Ping Luo
I am trying to configure Galaxy v18.09 wtih sub-uri. In prior 18.01, I use
this configuration in conjunction with Apache rewrite rules and it works
well:

[filter:proxy-prefix]
use = egg:PasteDeploy#prefix
prefix = /msgalaxy
[app:main]
filter-with = proxy-prefix
cookie_path = '/galaxy'


In galaxy.yml, I know I need to uncomment and add the following

filter-with: proxy-prefix
cookie_path: '/galaxy'

However, I don't know where and how to add filter:proxy-prefix. The comment
in config.yml says:

  # If running behind a proxy server and Galaxy is served from a
  # subdirectory, enable the proxy-prefix filter and set the prefix in
  # the [filter:proxy-prefix] section above.

which is for galaxy.ini file. An example on how to do it would be much
appreciated.

Ping
___
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/

Re: [galaxy-dev] V18.01 'View all histories' doesn't work

2018-05-15 Thread Ping Luo
Yes, we are hosting it at a prefix.

On Tue, May 15, 2018 at 11:30 AM, Dannon Baker <dannon.ba...@gmail.com>
wrote:

> Are you perhaps hosting at a prefix using proxy-prefix (so, instead of
> `/api/histories` we should be looking for `/mygalaxy/api/histories`, or the
> like)?  I'll take a quick look, this should be an easy fix.
>
> On Tue, May 15, 2018 at 12:25 PM Ping Luo <luop0...@gmail.com> wrote:
>
>> The Galaxy log file shows:
>>  [15/May/2018:11:20:44 -0500] "GET /template/api/webhooks HTTP/1.1" 200 -
>> "https://xxx.xxx.xxx/template/history/view_multiple; "Mozilla/5.0
>> (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
>> Chrome/66.0.3359.170 Safari/537.36"
>>
>> The apache log file shows:
>>  [15/May/2018:11:20:44 -0500] "GET /api/histories?limit=1=
>> 0=update_time=dev-detailed=encoded_id-in=
>> deleted=2e2f04bac8f3fcbc=None HTTP/1.1" 404 211
>>
>> Where else can I find more information?
>>
>>
>> On Tue, May 15, 2018 at 11:03 AM, Devon Ryan <dprya...@gmail.com> wrote:
>>
>>> You’ll probably get a more informative error message if you check the
>>> logs.
>>>
>>> Sent from my iPhone
>>>
>>> > On 15. May 2018, at 17:45, Ping Luo <luop0...@gmail.com> wrote:
>>> >
>>> > I just installed Galaxy V18.01. I got an error when clicking 'View all
>>> histories' in the history tool bar 
>>> >
>>> > The error says 'The requested URL /api/histories was not found on this
>>> server'.
>>> > 
>>> >
>>> > Is there anyone experiencing the same problem?
>>> >
>>> > Ping
>>> > ___
>>> > 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/
>>>
>>
>> ___
>> 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/
>
>
___
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/

Re: [galaxy-dev] V18.01 'View all histories' doesn't work

2018-05-15 Thread Ping Luo
The Galaxy log file shows:
 [15/May/2018:11:20:44 -0500] "GET /template/api/webhooks HTTP/1.1" 200 - "
https://xxx.xxx.xxx/template/history/view_multiple; "Mozilla/5.0 (Windows
NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/66.0.3359.170 Safari/537.36"

The apache log file shows:
 [15/May/2018:11:20:44 -0500] "GET /api/histories?limit=1=
0=update_time=dev-detailed=encoded_id-in=
deleted=2e2f04bac8f3fcbc=None HTTP/1.1" 404 211

Where else can I find more information?


On Tue, May 15, 2018 at 11:03 AM, Devon Ryan <dprya...@gmail.com> wrote:

> You’ll probably get a more informative error message if you check the
> logs.
>
> Sent from my iPhone
>
> > On 15. May 2018, at 17:45, Ping Luo <luop0...@gmail.com> wrote:
> >
> > I just installed Galaxy V18.01. I got an error when clicking 'View all
> histories' in the history tool bar 
> >
> > The error says 'The requested URL /api/histories was not found on this
> server'.
> > 
> >
> > Is there anyone experiencing the same problem?
> >
> > Ping
> > ___
> > 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/
>
___
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/

[galaxy-dev] V18.01 'View all histories' doesn't work

2018-05-15 Thread Ping Luo
I just installed Galaxy V18.01. I got an error when clicking 'View all
histories' in the history tool bar

The error says 'The requested URL /api/histories was not found on this
server'.


Is there anyone experiencing the same problem?

Ping
___
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/

Re: [galaxy-dev] Galaxy v17.09 impersonation doesn't work

2017-12-20 Thread Ping Luo
Hans-Rudolf,

I just started a brand new galaxy with the default internal database. I did
the minimal change to galaxy.ini so that I could use CAS authentication.
Still, impersonation failed.


Ping

On Wed, Dec 20, 2017 at 3:02 AM, Hans-Rudolf Hotz <h...@fmi.ch> wrote:

> Hi Ping
>
>
> Does it work with a fresh installation ( v17.09) staring with an empty
> PostgrSQL database?
>
>
> Hans-Rudolf
>
> On 12/19/2017 03:41 PM, Ping Luo wrote:
>
>> Hans-Rudolf,
>>
>> Yes, I have set the flag to be true
>>
>>  # Allow administrators to log in as other users (useful for
>> debugging)
>>  allow_user_impersonation = True
>>
>> We use CAS authentication and our database is Postgresql. Our current
>> Galaxy is v15.07 and impersonation works well. I have tried v16.10
>> before and impersonation didn't work either.
>>
>> Thanks,
>>
>> Ping
>>
>> On Tue, Dec 19, 2017 at 5:12 AM, Hans-Rudolf Hotz <h...@fmi.ch
>> <mailto:h...@fmi.ch>> wrote:
>>
>> Hi Ping
>>
>> The 'impersonate a user' function works for me with v17.09.
>>
>>
>> I assume, you have set: "allow_user_impersonation = True" in the
>> galaxy.ini file?
>>
>>
>> Do you encounter this problem, for the first time, i.e did it work
>> before using (v17.05 or earlier) and you only have the issues after
>> upgrading?
>>
>> What database do you use?
>>
>> Do you use external authentication?
>>
>>
>> Regards, Hans-Rudolf
>>
>>
>>
>>
>>
>>
>> On 12/18/2017 05:22 PM, Ping Luo wrote:
>>
>> The impersonation feature in Galaxy v17.09 doesn't work as
>> expected.
>>
>> After clicking the person to impersonate, the webpage shows "you
>> have
>> now logged in as xxx, return to home page', where 'xxx' is the
>> name of
>> the person I want to impersonate. So far so good. But after I
>> click
>> home, and check the login information, the login name is still
>> myself.
>>
>> Is there anything I missed in the configuration file?
>>
>> Thanks,
>>
>> Ping
>>
>>
>> ___
>> 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.o
>> rg/>
>>
>> To search Galaxy mailing lists use the unified search at:
>> http://galaxyproject.org/search/ <http://galaxyproject.org/sear
>> ch/>
>>
>>
>>
___
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/

Re: [galaxy-dev] Galaxy v17.09 impersonation doesn't work

2017-12-19 Thread Ping Luo
Hans-Rudolf,

Yes, I have set the flag to be true

# Allow administrators to log in as other users (useful for debugging)
allow_user_impersonation = True

We use CAS authentication and our database is Postgresql. Our current
Galaxy is v15.07 and impersonation works well. I have tried v16.10 before
and impersonation didn't work either.

Thanks,

Ping

On Tue, Dec 19, 2017 at 5:12 AM, Hans-Rudolf Hotz <h...@fmi.ch> wrote:

> Hi Ping
>
> The 'impersonate a user' function works for me with v17.09.
>
>
> I assume, you have set: "allow_user_impersonation = True" in the
> galaxy.ini file?
>
>
> Do you encounter this problem, for the first time, i.e did it work before
> using (v17.05 or earlier) and you only have the issues after upgrading?
>
> What database do you use?
>
> Do you use external authentication?
>
>
> Regards, Hans-Rudolf
>
>
>
>
>
>
> On 12/18/2017 05:22 PM, Ping Luo wrote:
>
>> The impersonation feature in Galaxy v17.09 doesn't work as expected.
>>
>> After clicking the person to impersonate, the webpage shows "you have
>> now logged in as xxx, return to home page', where 'xxx' is the name of
>> the person I want to impersonate. So far so good. But after I click
>> home, and check the login information, the login name is still myself.
>>
>> Is there anything I missed in the configuration file?
>>
>> Thanks,
>>
>> Ping
>>
>>
>> ___
>> 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/
>>
>>
___
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/

[galaxy-dev] Galaxy v17.09 impersonation doesn't work

2017-12-18 Thread Ping Luo
The impersonation feature in Galaxy v17.09 doesn't work as expected.

After clicking the person to impersonate, the webpage shows "you have now
logged in as xxx, return to home page', where 'xxx' is the name of the
person I want to impersonate. So far so good. But after I click home, and
check the login information, the login name is still myself.

Is there anything I missed in the configuration file?

Thanks,

Ping
___
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/

[galaxy-dev] impersonation doesn't work in v16.10

2017-01-25 Thread Ping Luo
I recently installed galaxy v16.10 and have set "allow_user_impersonation =
True". However, the impersonation feature seems don't work properly. When I
click "Admin->impersonate a user" and choose the account I want to
impersonate, and the click "impersonate" button. The page shows "you have
login as xxx, return to the homepage". But when I click homepage, the
actual login user is still my account.

I have been using galaxy v1507 and I have never had any problem with
impersonation. I am not sure if this is a bug in v1610 or I just miss
something.

Ping
___
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] Current directory in the galaxy job file script

2015-09-22 Thread Ping Luo
I installed the latest Galaxy (v15.07) and tested with a job. I found my
local environment setup file was not executed. The line of code that
executes the local setup file is

[ -f "config/local_env.sh" ] && . config/local_env.sh

Further looking into the galaxy_xx.sh file shows the current directory of
the script is $working_directory before "cd $working_directory" is
executed. This is not the case in previous versions, where the job's
current directory is the root of the Galaxy server in the beginning, until
"cd $working_directory" is executed.

I think making the current directory first at the root of the Galaxy server
is better since I don't need to put a full path in galaxy.ini for the
environment_setup_file. Will you change this back to it was?


Thanks,

Ping
___
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] Unable to connect galaxy server after upgrade to latest version

2015-01-16 Thread Ping Luo
I installed the latest galaxy server and started it without any change. The
server stared on port 8080 and the log file looks fine. But when I typed
http://localhost:8080, I got the error Unable to connect. I had worked
with version 2014_08_11 and had no problem at all. What could have been
wrong?
___
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/