This breaks some of the tools we're developing, although in our case it's
harder to fix because it's Javascript we're inserting.
I understand the security concerns though. Any advice on a more secure way
to allow particular content? Perhaps a whitelist of allowed scripts?
On Wed, Feb 1, 2012 at
A tool whitelist is an interesting idea that deserves more thought, but for now
I'm going to add an option to the galaxy configuration to easily enable or
disable the extended html filtering entirely. It'll be enabled by default, but
this should make it easier for the administrators of local
Hi Cory,
The new call to sanitize_html was introduced to more effectively prevent
malicious content and possible XSS attacks, though I can't think off the
top of my head why we couldn't allow style content. I'll see what I can
do about relaxing the filter a little.
Thanks!
-Dannon
On
Hi Dannon and thanks for the response!
I can see the need to sanitize incoming HTTP request parameters that may have
malicious content. However, I'm unclear as to why this also needs to happen
for HTML pages outputted by the Galaxy tools? If they have been generated with
sanitized HTTP
On 02/01/2012 03:41 PM, Cory Spencer wrote:
Hi Dannon and thanks for the response!
I can see the need to sanitize incoming HTTP request parameters that may have
malicious content. However, I'm unclear as to why this also needs to happen
for HTML pages outputted by the Galaxy tools? If they
On 2012-02-01, at 1:33 PM, Dannon Baker wrote:
With Galaxy's toolbox at hand you could generate invalid HTML from plain text
components. A simple example, but consider the following:
Upload one plain text file with the content:
script
Change the type of this dataset to html
Hello all -
One of the Galaxy tools I've been developing generates HTML output which I'd
styled using a style.../style tag in the HTML header. After updating to
the latest Galaxy release earlier today, the html, head.../head, style
and body tags started to get stripped from the output,
