Dear All,
I have recently started to receive errors like that while new LDAP users are trying to access the history or upload a file, while they can log into galaxy just fine. Everything under /home/galaxy is owned by galaxy:galaxy. I am using apache proxy. Details of error:
galaxy.web.framework.decorators ERROR 2015-09-21 12:48:09,338 Uncaught exception in exposed API method: Traceback (most recent call last): File "/home/galaxy/galaxy-dist/lib/galaxy/web/framework/decorators.py", line 135, in decorator rval = func( self, trans, *args, **kwargs) File "/home/galaxy/galaxy-dist/lib/galaxy/webapps/galaxy/api/tools.py", line 234, in create target_history = self.history_manager.get_owned( decoded_id, trans.user, current_history=trans.history ) File "/home/galaxy/galaxy-dist/lib/galaxy/managers/secured.py", line 94, in get_owned return self.error_unless_owner( item, user, **kwargs ) File "/home/galaxy/galaxy-dist/lib/galaxy/managers/secured.py", line 104, in error_unless_owner raise exceptions.ItemOwnershipException( "%s is not owned by user" % ( self.model_class.__name__ ) ) ItemOwnershipException: History is not owned by user
Hi Zuzanna
This sort of rings a bell...can you give some more details:
- Have you always used external authentication? or do you get this problem after switching to external authentication?
- what do you mean by "new LDAP users"?
- Are you sure, you get the "correct information" back from the LDAP server? Maybe the LDAP server gave you e-mail addresses in all lower cases, and now somebody has changed something , and the LDAP server returns e-mail addresses in camel case?
- Have a look at Admin -> Manage users Do you have duplications of users?
- Have you looked into the PostgreSQL database and checked the ownership of the histories in question.
I hope this gives you a few points to look into
Regards, Hans-Rudolf
On 09/21/2015 01:00 PM, Zuzanna K. Filutowska wrote:
Dear All,
I have recently started to receive errors like that while new LDAP users are trying to access the history or upload a file, while they can log into galaxy just fine. Everything under /home/galaxy is owned by galaxy:galaxy. I am using apache proxy. Details of error:
galaxy.web.framework.decorators ERROR 2015-09-21 12:48:09,338 Uncaught exception in exposed API method: Traceback (most recent call last): File "/home/galaxy/galaxy-dist/lib/galaxy/web/framework/decorators.py", line 135, in decorator rval = func( self, trans, *args, **kwargs) File "/home/galaxy/galaxy-dist/lib/galaxy/webapps/galaxy/api/tools.py", line 234, in create target_history = self.history_manager.get_owned( decoded_id, trans.user, current_history=trans.history ) File "/home/galaxy/galaxy-dist/lib/galaxy/managers/secured.py", line 94, in get_owned return self.error_unless_owner( item, user, **kwargs ) File "/home/galaxy/galaxy-dist/lib/galaxy/managers/secured.py", line 104, in error_unless_owner raise exceptions.ItemOwnershipException( "%s is not owned by user" % ( self.model_class.__name__ ) ) ItemOwnershipException: History is not owned by user
Dnia 2015-09-21, pon o godzinie 13:55 +0200, Hans-Rudolf Hotz pisze:
Hi Zuzanna
This sort of rings a bell...can you give some more details:
- Have you always used external authentication? or do you get this
problem after switching to external authentication?
Yes, I always used external auth.
- what do you mean by "new LDAP users"?
Users that newly log on Galaxy today.
- Are you sure, you get the "correct information" back from the LDAP
server? Maybe the LDAP server gave you e-mail addresses in all lower cases, and now somebody has changed something , and the LDAP server returns e-mail addresses in camel case?
Yes, old users can log in, and new users also can log in but they can't upload files or histories - they are getting internal server error while uploading and 403 errors while trying to upload history and the error shows "This API requires authentication"
- Have a look at Admin -> Manage users Do you have duplications of
users?
No.
- Have you looked into the PostgreSQL database and checked the
ownership of the histories in question.
How can I do that?
I hope this gives you a few points to look into
I have a hunch that this maybe something in system permissions but I looked throught the galaxy tree and I see galaxy is the owner of all files. I am used mod_xsendfile.
Dnia 2015-09-21, pon o godzinie 13:55 +0200, Hans-Rudolf Hotz pisze:
After turning off mod_xsendfile nothing changed, so I assume it is not at fault.
Ok, it is not the same problem we have encountered a few years ago.
I doubt, that it is a system permission issue. All data files belong to galaxy (or the user the galaxy server is running as), and the access is regulated by the PostgreSQL (or MySQL or SQlite) database. I can only imagine the following case: you have restarted the Galaxy server as a different user than before?
To me, it rather looks like something has changed in the apache set-up and I am not an expert on this. I hope some-else can pick up this e-mail thread
Hans-Rudolf
On 09/21/2015 02:05 PM, Zuzanna K. Filutowska wrote:
Dnia 2015-09-21, pon o godzinie 13:55 +0200, Hans-Rudolf Hotz pisze:
Hi Zuzanna
This sort of rings a bell...can you give some more details:
- Have you always used external authentication? or do you get this
problem after switching to external authentication?
Yes, I always used external auth.
- what do you mean by "new LDAP users"?
Users that newly log on Galaxy today.
- Are you sure, you get the "correct information" back from the LDAP
server? Maybe the LDAP server gave you e-mail addresses in all lower cases, and now somebody has changed something , and the LDAP server returns e-mail addresses in camel case?
Yes, old users can log in, and new users also can log in but they can't upload files or histories - they are getting internal server error while uploading and 403 errors while trying to upload history and the error shows "This API requires authentication"
- Have a look at Admin -> Manage users Do you have duplications of
users?
No.
- Have you looked into the PostgreSQL database and checked the
ownership of the histories in question.
How can I do that?
I hope this gives you a few points to look into
I have a hunch that this maybe something in system permissions but I looked throught the galaxy tree and I see galaxy is the owner of all files. I am used mod_xsendfile.
Dnia 2015-09-21, pon o godzinie 15:14 +0200, Hans-Rudolf Hotz pisze:
Ok, it is not the same problem we have encountered a few years ago.
I doubt, that it is a system permission issue. All data files belong to galaxy (or the user the galaxy server is running as), and the access is regulated by the PostgreSQL (or MySQL or SQlite) database. I can only imagine the following case: you have restarted the Galaxy server as a different user than before?
No. I always use the galaxy user. I am using PostgreSQL as the db backend.
To me, it rather looks like something has changed in the apache set-up and I am not an expert on this. I hope some-else can pick up this e-mail thread
I have recently configured Galaxy to run in multiprocess setup using the docs on Galaxy site.
I would be grateful for help as we are now running the series of workshops for new Galaxy users.
Dnia 2015-09-21, pon o godzinie 15:14 +0200, Hans-Rudolf Hotz pisze:
I have created a new test user, and here is the output, when trying to import and show imported histories (/history/view_multiple) { "agent": "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0", "url": "http://galaxy.man.poznan.pl/history/view_multipl/api/histories/85b413e771c18...", "data": "", "options": { "data": {}, "silent": true, "parse": true, "emulateHTTP": false, "emulateJSON": false }, "xhr": { "readyState": 4, "responseText": "{"err_msg": "API authentication required for this request", "err_code": 403001}", "responseJSON": { "err_msg": "API authentication required for this request", "err_code": 403001 }, "status": 403, "statusText": "Forbidden", "responseHeaders": { "Date": "Mon, 21 Sep 2015 14:37:59 GMT\r", "Server": "PasteWSGIServer/0.5 Python/2.7.10\r", "X-Frame-Options": "SAMEORIGIN\r", "Content-Type": "text/html; charset=UTF-8\r", "Vary": "Accept-Encoding\r", "Content-Encoding": "gzip\r", "Connection": "close\r", "Transfer-Encoding": "chunked\r" } }, "source": [], "user": { "username": "plgjdoe", "quota_percent": null, "total_disk_usage": 20139875, "nice_total_disk_usage": "19.2 MB", "email": "plgjdoe@galaxy.man.poznan.pl", "is_admin": false, "tags_used": [], "model_class": "User", "id": "3cc0effd29705aa3" } }
I'm stumped:
- I'm not sure how that url (" http://galaxy.man.poznan.pl/history/view_multipl/api/histories/85b413e771c18...") could have been formed - Calling that link from a local galaxy results in 'No route for' when the error is an api authentication 403
Maybe it's possible that an authentication error is confounding/combining with a client error?
Zuzanna, can you:
- tell us what version of Galaxy you're using? - open a javascript console on the history/view_multiple page and see what it says 'galaxy_conf.root' equals?
On Mon, Sep 21, 2015 at 10:39 AM, Zuzanna K. Filutowska < platyna@man.poznan.pl> wrote:
Dnia 2015-09-21, pon o godzinie 15:14 +0200, Hans-Rudolf Hotz pisze:
I have created a new test user, and here is the output, when trying to import and show imported histories (/history/view_multiple) { "agent": "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0", "url": " http://galaxy.man.poznan.pl/history/view_multipl/api/histories/85b413e771c18... ", "data": "", "options": { "data": {}, "silent": true, "parse": true, "emulateHTTP": false, "emulateJSON": false }, "xhr": { "readyState": 4, "responseText": "{"err_msg": "API authentication required for this request", "err_code": 403001}", "responseJSON": { "err_msg": "API authentication required for this request", "err_code": 403001 }, "status": 403, "statusText": "Forbidden", "responseHeaders": { "Date": "Mon, 21 Sep 2015 14:37:59 GMT\r", "Server": "PasteWSGIServer/0.5 Python/2.7.10\r", "X-Frame-Options": "SAMEORIGIN\r", "Content-Type": "text/html; charset=UTF-8\r", "Vary": "Accept-Encoding\r", "Content-Encoding": "gzip\r", "Connection": "close\r", "Transfer-Encoding": "chunked\r" } }, "source": [], "user": { "username": "plgjdoe", "quota_percent": null, "total_disk_usage": 20139875, "nice_total_disk_usage": "19.2 MB", "email": "plgjdoe@galaxy.man.poznan.pl", "is_admin": false, "tags_used": [], "model_class": "User", "id": "3cc0effd29705aa3" } } --
Pozdrawiam,
-- Zuzanna K. Filutowska, HPC Systems Administrator Poznan Supercomputing and Networking Center Institute of Bioorganic Chemistry Polish Academy of Sciences Seize the day boys! Make your lifes extraordinary! --John Keating
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/
Dnia 2015-09-21, pon o godzinie 13:29 -0400, Carl Eberhard pisze:
I'm stumped: * I'm not sure how that url ("http://galaxy.man.poznan.pl/history/view_multipl/api/histories/85b413e771c18...") could have been formed * Calling that link from a local galaxy results in 'No route for' when the error is an api authentication 403 Maybe it's possible that an authentication error is confounding/combining with a client error?
Client is only a user of a browser (I have checked several browsers).
Zuzanna, can you: * tell us what version of Galaxy you're using?
It is newest from git - 15.07.
* open a javascript console on the history/view_multiple page and see what it says 'galaxy_conf.root' equals?
I can't find anything like that (I am using openjdk with firefox built in js console). This is what it shows me: URL żądania: http://galaxy.man.poznan.pl/api/histories/85b413e771c184a9/contents Metoda żądania: GET Kod stanu: HTTP/1.1 403 Forbidden Nagłówki żądania 20:54:21.000 X-Requested-With: XMLHttpRequest User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0 Referer: http://galaxy.man.poznan.pl/history/view_multiple Host: galaxy.man.poznan.pl Connection: keep-alive Authorization: Basic cGxnamRvZTpONG4zazQuMjMyMw== Accept-Language: pl,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Accept: application/json, text/javascript, */*; q=0.01 Nagłówki odpowiedzi Δ27ms X-Frame-Options: SAMEORIGIN Vary: Accept-Encoding Transfer-Encoding: chunked Server: PasteWSGIServer/0.5 Python/2.7.10 Date: Mon, 21 Sep 2015 18:54:21 GMT Content-Type: text/html; charset=UTF-8 Content-Encoding: gzip Connection: close However my galaxy root is /home/galaxy/galaxy-dist (I am using mod_rewrite).
I think this problem has been introduced with galaxy multiprocess setup, but it affects new users therefore we didn't find it before workshop. Old users works fine. I checked my ldap server and those users are in there.
Dnia 2015-09-21, pon o godzinie 13:29 -0400, Carl Eberhard pisze:
I'm stumped: * I'm not sure how that url ("http://galaxy.man.poznan.pl/history/view_multipl/api/histories/85b413e771c18...") could have been formed * Calling that link from a local galaxy results in 'No route for' when the error is an api authentication 403 Maybe it's possible that an authentication error is confounding/combining with a client error?
Zuzanna, can you: * tell us what version of Galaxy you're using? * open a javascript console on the history/view_multiple page and see what it says 'galaxy_conf.root' equals?
It took me 13 hours to figure it out but it seems that the problem was caused by this: RequestHeader set X-URL-SCHEME https
inside my <Location />.
I have set it according to the docs: https://wiki.galaxyproject.org/Admin/Config/ApacheProxy as I use apache proxy with SSL, but without it the proxy works fine, as well as uploads and history import. Maybe this case is worth mentioning in the docs.
Glad you figured it out! So a page served via https is generating links for http references that should have been https?
On Mon, Sep 21, 2015 at 5:15 PM, Zuzanna K. Filutowska < platyna@man.poznan.pl> wrote:
Dnia 2015-09-21, pon o godzinie 13:29 -0400, Carl Eberhard pisze:
I'm stumped: * I'm not sure how that url ("
http://galaxy.man.poznan.pl/history/view_multipl/api/histories/85b413e771c18...") could have been formed
* Calling that link from a local galaxy results in 'No route for' when the error is an api authentication 403Maybe it's possible that an authentication error is confounding/combining with a client error?
Zuzanna, can you: * tell us what version of Galaxy you're using? * open a javascript console on the history/view_multiple page and see what it says 'galaxy_conf.root' equals?
It took me 13 hours to figure it out but it seems that the problem was caused by this: RequestHeader set X-URL-SCHEME https
inside my <Location />.
I have set it according to the docs: https://wiki.galaxyproject.org/Admin/Config/ApacheProxy as I use apache proxy with SSL, but without it the proxy works fine, as well as uploads and history import. Maybe this case is worth mentioning in the docs.
--
Pozdrawiam,
-- Zuzanna K. Filutowska, HPC Systems Administrator Poznan Supercomputing and Networking Center Institute of Bioorganic Chemistry Polish Academy of Sciences Seize the day boys! Make your lifes extraordinary! --John Keating
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/
Dnia 2015-09-21, pon o godzinie 17:20 -0400, Dannon Baker pisze:
Glad you figured it out! So a page served via https is generating links for http references that should have been https?
It was my first thought, but then when I used http/http (accessed galaxy via http to see if protocol mismatch is causing the problem). I also got this error. All combinations: http/http, https/https and http/https generated this problem. Very weird problem.
galaxy-dev@lists.galaxyproject.org
-
Carl Eberhard -
Dannon Baker -
Hans-Rudolf Hotz -
Zuzanna K. Filutowska