Return HTML rendering

[dkp]

I am very disappointed that you have elected to remove the HTML rending capabilities from OOD. I understand that you had some security concerns, however, because the quality control reports our neuroimaging software generates are almost entirely in HTML, now there is no quick easy way to review those reports ; ( I hope you will consider adding back some HTML rendering support.

┆Issue is synchronized with this Asana task by Unito

[Oglopf]

Given the use case of how the view is intended to be used in this domain I think this makes sense to add as a configuration option.

The model for the files.rb class would need modified to allow for text/html; charset=utf-8 at line 138 to be returned, where currrently the files are forced to text/plain; charset=utf-8 in all cases.

This could be done in the files app's model logic by adding a method to congiruation_singleton.rb with a name like files_enable_html_view which returns a boolean that users can set in a ondemand.d/*.yml file, and which would allow the files' model to return text/html; charset=utf-8 if Configuration.files_enable_html_view returns true with the remainder of the else left intact.

Test cases would need added as well as updated documentation about this option.

[johrstrom]

Hey yea thanks for the ticket. Yea we have security concerns, but I definitly think that we will add this back once we have strong Content Security Policies.

[wasciutto]

Just want to second dkp's concern, our lab relied on this html rendering feature to view neuroimaging reports as well. Thanks for opening an issue!

[johrstrom]

Can you let me know what the stack is and/or share the output html files?

Once we harden our content security policy we can enable it back - but the view may be a little odd if it relies on css (that's not bootstrap) or javascript.

[dkp]

sub-075_T1w.html.zip I'm attaching a sample neuroimaging report. Thanks for working on this.

[GKlouse]

I would like to sound off here as well. Our software documentations is html-based and we would like users to be able to access them from our beegfs network within the portal front-end. I understand the security concerns... could this be wrapped up in a Custom App for users to only see the HTML we want them to see?

[johrstrom]

You can host public static html through /var/www/ood/public/ and generate links to them.

This feature is more like - I'm navigating the filesystem through Open OnDemand and click on an html file. Just want to be sure you're use case is one or the other,

[dkp]

Thank you. My use case is like the second one: I'm navigating the file system through OOD and I want to click on an HTML file and render it (not look at the source code).

[camarocico]

Hi all,

We also have users that are used to view the html files directly in the OOD portal. Maybe a "Render" or "Display" option in the context menu?

Cristian

[johrstrom]

I think I have a solution that's simple enough to make it into the 2.1 release and it's this:

Viewing html files will cause the file to download and open the local file in a new tab. This means it can bypass our CSP because we're not serving it - it's local to the users machine.

This would also an an Are you sure? You should only view html from trusted sources type dialogue with a checkbox to not show again.

[GKlouse]

To share with everyone involved, one solution we implemented to keep our documentation behind a secure login, yet able to be rendered in the OOD 2.0 html interface was to link a master HTML doc to the apache hosted "Online Documentation" link.

We pointed it to a common location which allows users to access any linked documentation within it, and it keeps it secure. We just have to manage it accordingly, but it is functional.

[dkp]

I think I have a solution that's simple enough to make it into the 2.1 release and it's this:

Viewing html files will cause the file to download and open the local file in a new tab. This means it can bypass our CSP because we're not serving it - it's local to the users machine.

This would also an an Are you sure? You should only view html from trusted sources type dialogue with a checkbox to not show again.

Would this work for an HTML file that relies on separate images? I'm thinking it wouldn't...

[johrstrom]

Would this work for an HTML file that relies on separate images? I'm thinking it wouldn't...

Sadly it would not and that's your primary use case. So I guess it's back to the drawing board.

[dkp]

Thanks for thinking about it; )

[bgizelarMCW]

Just want to second dkp's concern, our lab relied on this html rendering feature to view neuroimaging reports as well. Thanks for opening an issue!

I just upgraded OOD and also have labs that relied on html rendering (view) as well to view reports from HPC job output. Requesting this functionality be put back in as we are also getting complaints about this missing from the labs. Thanks!

[multimeric]

Just trying to understand the security concerns here. If a malicious actor had access to the filesystem, I suppose they could create an HTML + JS application which could make authenticated requests to OnDemand using the session cookies if a user opened that file. Whereas downloading the HTML means the page doesn't have access to any of the OnDemand user data. So I can see why this is currently preferred.

[dkp]

Hi All, So is there a verdict on this? I get that there are some legitimate security concerns. Does that mean that OOD has lost the capability to view HTML that contains embedded javascript forever? (Or is there still hope?)

[johrstrom]

So is there a verdict on this? I get that there are some legitimate security concerns. Does that mean that OOD has lost the capability to view HTML that contains embedded javascript forever? (Or is there still hope?)

Not forever. We'll enable it when we can safely do so.

[dkp]

Thank you.

[multimeric]

I'm interested in how you envisage this might be enabled safely?

What I'm thinking is that we could serve HTML through a sanitiser. I believe this is what e.g. OnDrive does when you open an HTML file inside the web app. It basically strips out "dangerous" elements like <script>, <iframe> etc but keeps the normal layout stuff. This breaks interactive features like navigation but it's generally better than nothing.

[johrstrom]

A strong content security policy. Right now we have one that you can enable and/or reconfigure, but we ourselves break a lot the rules it so it's not enabled.