qiime2view does not work if Galaxy is behind a firewall

[bernt-matthias]

If Galaxy is behind a firewall, then the qiime2view visualization does not work. Currently the visualization sends a link to the viz website which does not work in such a setup.

Wondering if it is possible to rewrite the viz plugin such that it sends the data directly .. and if the qiime2view website would support getting data directly.

[bernt-matthias]

Alternatively I might ask our admins if certain URLs may be exempted from the firewall rules.

[bernt-matthias]

Some more alternatives:

• Maybe its possible to create a charts plugin for qiime2view https://training.galaxyproject.org/training-material/topics/dev/tutorials/visualization-charts/tutorial.html .. it should qualify: https://training.galaxyproject.org/training-material/topics/dev/tutorials/visualization-generic/slides.html#9
• Install qiime2view locally. URL can be configured in tool-data/q2view_display.loc.sample

[bernt-matthias]

Just had another idea: In galaxy there is a static/ directory. Was trying to follow the build instructions from https://github.com/qiime2/q2view and copy the result (the build dir into Galaxy's static dir).

In my case I have a nginx directive:

	location /static {
		alias /data/galaxy_server/galaxy-dev/static;
		expires 24h;
	}

Problem is then that within q2view there seem to be many relative path (eg. ./js/bundle-639d8d1dd3e4440cf7af.js) which seem not to work. I started to replace ./ by /static/, which led to some progress.

Now I'm wondering if there is a better way to do this, i.e. serving q2view from a subdir of the webserver....

@ebolyen do you have an idea or know someone who could help?

[bernt-matthias]

As a workaround: galaxyproject/tools-iuc#4834

[ebolyen]

Hey @bernt-matthias,

Sorry for having missed this issue!

I'm going to write a big comment with inline quotes.

Wondering if it is possible to rewrite the viz plugin such that it sends the data directly .. and if the qiime2view website would support getting data directly.

This isn't quite possible because q2view is actually a static website with a ton of javascript to invent a client-side web-server (via a Service Worker) that makes the browser think it's talking to a server (when it's actually just a QZV).

Alternatively I might ask our admins if certain URLs may be exempted from the firewall rules.

This is probably the best bet for most people. q2view doesn't upload any actual data to any actual server, although I can definitely respect that some sysadmins are indifferent to that claim (it is a website that in principle, could do anything with the data).

Maybe its possible to create a charts plugin for qiime2view https://training.galaxyproject.org/training-material/topics/dev/tutorials/visualization-charts/tutorial.html .. it should qualify: https://training.galaxyproject.org/training-material/topics/dev/tutorials/visualization-generic/slides.html#9

I think that's probably the best long-term solution, I just had absolutely no idea how to go about it. Thanks for the resources!

Install qiime2view locally. URL can be configured in tool-data/q2view_display.loc.sample

That should work too, although now you have to build q2view from a webpack config I haven't touched in some time. So it's unlikely to be pleasant.

Just had another idea: In galaxy there is a static/ directory. Was trying to follow the build instructions from https://github.com/qiime2/q2view and copy the result (the build dir into Galaxy's static dir). [...] Now I'm wondering if there is a better way to do this, i.e. serving q2view from a subdir of the webserver....

That should in principle work just fine. But I'll need to modify the aforementioned webpack config to tolerate relative root directories for the application. Not the end of the world, but definitely all of the pain that comes with updating and compiling a javascript project from the 2016-18 era of webdev w/ webpack.

As a workaround: galaxyproject/tools-iuc#4834

This looks great to me! And is indeed exactly all q2view ever did. I assume Galaxy has some provision to avoid client-side attacks from running arbitrary HTML such as an alternative domain or port? (I promise we aren't nefarious, but we'd hate to be the cause of any issues.)

Also the jsonp -> js rewrite shouldn't cause any issues in practice, so that also seems totally fine. The reason some of our visualizations do that is so that you can use them with the default file://path/index.html schema in most browsers. However since each path is it's own domain in that protocol-scheme, it meant we needed to use the old school cross-domain tricks instead of anything reasonable.

That's actually something that causes enough issues in practice we'll probably at some point just expect that visualizations are running in an HTTP hosted directory.

[bernt-matthias]

Thanks for the detailed comments. In the long run a generic/viz plugin in Galaxy could be nice... but I guess it will need time to develop it which is scarce.

This looks great to me! And is indeed exactly all q2view ever did.

Cool. Wondering if a tighter integration in the qiime tools would be an idea? With the additional tool an extra tool run would be needed to extract the qzv to html. Maybe all tools generating qzv could just have an extra/alternative output (ie the html file). Might be more userfriendly...

Btw. are qzv files dead ends or are there tools that can process qzv further?

I assume Galaxy has some provision to avoid client-side attacks from running arbitrary HTML such as an alternative domain or port? (I promise we aren't nefarious, but we'd hate to be the cause of any issues.)

I don't know. By default the html page will not be rendered at all, but admins will need to put the tool on an allowlist. If this is done I'm not sure if there are any security measures. I will ask in the Galaxy gitter channels.