I have been extending the LWR so that one can now stand up public LWR
servers (https://lwr.readthedocs.org/en/latest/#setting-up-a-public-lwr-server),
the idea is that you can publicly share data and computation with any
Galaxy instances in the world easily and seamlessly via vanilla Galaxy
tools. This could serve the foundation of a distributed service
architecture where tools are the contracts, Galaxy instances the
clients, and LWRs the server containers.

One thing that did need to change with the LWR is that inputs need to
be validated. It would obviously not be a good idea to allow arbitrary
command-line or script executions to unauthenticated clients.

This was accomplished in part by allowing you to configure a Galaxy
toolbox or tool_conf file for the LWR. The LWR reads validation logic
for command-line and configfiles from the XML and verifies them before

The test cases I used to build up this validation extension to the
tool XML can be found here:


Question 1: Would Galaxy benefit from implementing this validation
stuff in the core framework as well? I think of myself as fairly
security conscious and my sense is no, but it could I see the
argument. There are potentially complex interactions between user
inputs and cheetah templates that one might sleep better knowing
everything is being validated before execution (the user didn't cause
the cheetah template to somehow render "; rm -rf /").

Question 2: Looking back on the validation stuff, it seems I am just
rewriting in XML what cheetah is doing. The duplication makes me think
the validation stuff might serve the foundation for a better (or at
least more secure) way to build up commands.

<command interpreter="python">
      <equals left="$refGenomeSource.genomeSource" right="history">
         <parameter name="--own_file">$refGenomeSource.ownFile</parameter>

The client could easily compile that into a cheetah template to build
the command, the server could compile it into a regular expression to
validate the input.

These aren't things that pressingly need to be added to the core
Galaxy framework, but things to think about longer term. If there is
any interest from the core Galaxy team I would be happy to implement
any of this with any desired changes.

Thanks all,

John Chilton
Senior Software Developer
University of Minnesota Supercomputing Institute
Office: 612-625-0917
Cell: 612-226-9223
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:


Reply via email to