From the scaling wiki page I've copied the setup of using a single runner Galaxy instance and multiple web front ends; in my case I'm running two web front ends. One of these web front ends lets Galaxy administrate users normally. The other front end I'm proxying through Apache while using the remote user feature, as specified on the Apache Proxy page. However, rather
Hi all, An update on this topic now that I've implemented a more satisfactory solution on how to allow anonymous users to run workflows. This problem arose when it became apparent that the journal we want to publish our workflow in had as explicit requirement that users not be required to register before using the web service. Galaxy at the moment requires users to register before allowing them to use workflows, so a solution had to be found. I've combined ingredients from two Galaxy wiki pages to make resolve this issue: http://wiki.g2.bx.psu.edu/Admin/Config/Performance/Web%20Application%20Scali... http://wiki.g2.bx.psu.edu/Admin/Config/Apache%20Proxy than relying on an external authentication mechanism, I've instead configured Apache to set the client's remote address as the remote user using the following directive: RequestHeader set REMOTE_USER '%{REMOTE_ADDR}s' This approach allows me to run a single normal web frontend allowing for normal registration, and another one available at a distinct subdomain using the client's IP address as implicit stable identifier. (I'm well aware IPs are not be stable for everyone, which is still the biggest caveat with this approach.) I'm hoping however this will still satisfy the editors for our publication. My intention to share this setup with the mailinglist is twofold: on the one hand this approach could be useful to others that have to implement the same requirements (no mandatory registration to run a workflow), while on the other hand my approach might unknowingly lead to problems down the road. Should this be the case please notify me how best to resolve this. Otherwise I'm quite happy using this approach. Best, Tim On Tue, Sep 6, 2011 at 5:00 PM, Tim te Beek <tim.te.beek@nbic.nl> wrote:
I completely agree it's a bit of an unfortunate requirement in this case, but I'm not averse to (minor) code changes to achieve a more polished user experience. Something like the best guess mechanism Galaxy currently employs to recognize returning anonymous would be fine, but I don't know where to look to disable the login requirement to run workflows, or if that's at all possible.
Best regards, Tim
On Tue, Sep 6, 2011 at 11:01 AM, Ross <ross.lazarus@gmail.com> wrote:
Here's one bad option for dealing with a bad requirement - at least it requires no code changes...
1. create a new user called demo@where.ever.org for your Galaxy. Do not require login in universe_wsgi.ini 2. edit welcome.html - invite visitors not wanting all the benefits of an individual registration to login as user:demo@where.ever.org if they want to run workflows 3. Add an extremely blunt disclaimer - although Galaxy will likely be behaving 'correctly', unusual things will happen whenever 2 or more users using the same account are banging away at the same history - Individual registration is strongly recommended - register a free account with a throw away email address - it's only for password recovery. Clearly registration is not mandatory - just sensible and free, so the journal's off your back. Hope that demo account isn't multitasking too often.
On Tue, Sep 6, 2011 at 6:17 PM, Tim te Beek <tim.te.beek@nbic.nl> wrote:
Hi all,
Was wondering how I can allow anonymous users to run workflows in my local Galaxy instance, as currently users need to be logged in to run workflows. I'd like drop this requirement in light of the intended publication of a workflow in a journal which demands that "Web services must not require mandatory registration by the user.". Could any you tell me how I can accomplish this?
I've seen the option to use an external authentication method which could be employed to artificially 'login' anonymous users for a single session, but it appears this would also disable the normal users administration mechanisms in Galaxy, so I'm not sure this would be a good fit. Any hints on how to proceed, either via this route or otherwise, would be much appreciated.
Best regards, Tim