Hi,

We also considered this while adding the web service tools but  were thinking this should not be an issue as the tools just invoke the Web services and all the code executed is on the Web server where the web service is hosted. All the tool does is get the result back (plain text for example) from the server.

Please let me know if  you think this can still cause security issues and
we can work further to see how we can improve our tools to consider the security threats, if any.

Pieter, I would suggest you try our tool posted on the community site
called "Suite of Web Service Addition Tools" under Data source category,
as it does exactly what you described in your post. Currently, it works for REST Web services and we are working on adding SOAP functionality to it.

Thanks,
Sumedha

On Wed, Nov 24, 2010 at 11:04 AM, Peter <peter@maubp.freeserve.co.uk> wrote:
On Wed, Nov 24, 2010 at 12:13 AM, Pieter Neerincx wrote:
> Hi,
>
> I'd love to have the ability to load tools dynamically as it would remove what
> I experience as the biggest draw back of web portals: in most cases you see
> 9 out of 10 tools that would be required for a job, but there's always a small
> piece of the puzzle missing. So you google for another web portal where this
> missing step is present just to figure out that over there it's another step that
> is missing.

I don't think the enhancements being discussed will change that (see below).

> Bugging sys admins to install that missing piece to complete the workflow
> is in many cases too much of a hassle, so it would be really nice to be able
> for end users to plug a web service for example from the BioCatalogue
> dynamically into Galaxy. Being able to dynamically plug a 3rd party package
> from the tool shed would also be great, but I can imagine this only works for
> simple scripts that install easily without too many dependencies.

In my opinion there is no way ordinary Galaxy users should be allowed to
install arbitrary Galaxy tools from 3rd party websites. It would be a massive
security hole as a malicious Galaxy tool could easily erase all the user data,
or worse - if coupled with a security privilege escalation attack, the malicious
tool could take over the whole server.

What we are talking about is making it easier for the administrators of a
Galaxy instance to install/update/remove tools without restarting Galaxy.
I would find this quite useful to testing my own tool wrappers.

> So I happy to see there's a ticket for this :)... I was just wondering where
> this ticket is on the priority list? More in general is there a way to see how
> the Galaxy team prioritizes tickets? This will influence whether I want to
> wait for the issue to be solved upstream or whether I'll hack my Galaxy
> based on the work from the University of Georgia...

I don't see any priority field, but issues on bitbucket can be marked with
a target milestone, however that doesn't currently seem to be used for
Galaxy:
http://bitbucket.org/galaxy/galaxy-central/issues?status=new&status=open

Regards,

Peter
_______________________________________________
galaxy-dev mailing list
galaxy-dev@lists.bx.psu.edu
http://lists.bx.psu.edu/listinfo/galaxy-dev