Re: [galaxy-dev] Galaxy strips CSS from HTML files
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 23:58, Cory Spencer cspen...@sprocket.org wrote: 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 and there's your attack. If you tried to upload this, we'd interpret it as malicious HTML and discard it. As separate datasets, it's impossible to tell. Given Galaxy's powerful text manipulation tools you could write just about whatever you wanted using Galaxy itself and get it in the system as a (seemingly) valid tool-generated dataset. Now, with the outbound sanitation on any dataset served as text/html it doesn't matter and it gets handled prior to serving. Okay, I follow you there. That's a good example, thank you! Another option we discussed would be to trust all tool generated HTML, disallow changing the datatype of anything *to* html, and so on, but that approach comes with its own problems. In the case of the tool we're working on, this option is probably what would have worked best. If anything, would it be possible to make this sort of sanitization controllable via a configuration file option? I'm rather hesitant to put in a disable option for a security feature, though you're more than welcome to pop those two lines out of your instance. I think the best path forward is probably relaxing the filter a bit, the initial pass was somewhat draconian. Would relaxing the filter to allow style content to pass through work for your needs? Yes, we've already commented it out for the time being. :) Relaxing the filter would be a good improvement so far as we're concerned. I'd be happy to keep in contact with you during the process so that we can find the happy middle ground between security and usability. Thanks again! Cory ___ 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: http://lists.bx.psu.edu/ -- Computational Biology Group University of Cape Town South Africa ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] GATK Depth of Coverage error
Hi Curt, This should be fixed in -central (https://bitbucket.org/galaxy/galaxy-central) in changeset 6778:35be930b21be and will be available in the next dist release. If you don't want to wait until the next dist release, you can also pull directly from central or apply the changes manually. Thanks for using Galaxy, Dan On Mar 1, 2012, at 5:12 PM, Curt Palm wrote: I am trying to run GATK's DepthOFCoverage using intervals and get the following error: failure preparing job Traceback (most recent call last): File /home/galaxy/galaxy-dist/lib/galaxy/jobs/runners/local.py, line 59, in run_job job_wrapper.prepare() File /home/galaxy/galaxy-dist/lib/galaxy/jobs/__init__.py, line 424, in prepare self.command_line = self.tool.build_command_line( param_dict ) File /home/galaxy/galaxy-dist/lib/galaxy/tools/__init__.py, line 1827, in build_command_line command_line = fill_template( self.command, context=param_dict ) File /home/galaxy/galaxy-dist/lib/galaxy/util/template.py, line 9, in fill_template return str( Template( source=template_text, searchList=[context] ) ) File /home/galaxy/galaxy-dist/eggs/Cheetah-2.2.2-py2.6-linux-x86_64-ucs4.egg/Cheetah/Template.py, line 1004, in __str__ return getattr(self, mainMethName)() File cheetah_DynamicallyCompiledCheetahTemplate_1330381526_3_23629.py, line 402, in respond NotFound: cannot find 'omit_interval_statistics' while searching for 'gatk_param_type.omit_interval_statistics' the parameters used are: Tool: Depth of Coverage Name: Depth of Coverage on data 35 and data 27 (per locus coverage) Created: Feb 27, 2012 Filesize: 0 bytes Dbkey:human_g1k_v37 Format: rtable Tool Version: None Tool Standard Output: stdout Tool Standard Error: stderr Input Parameter Value Conditional (reference_source)0 BAM file 35: Table Recalibration on data 33, data 31, and data 27 (BAM) Using reference genomehuman_g1k_v37 RefSeq RodNo dataset Partition type for depth of coverage sample Output format rtable Conditional (gatk_param_type) 1 How strict should we be in validating the pedigree informationSTRICT Genomic intervals 27: 5um_amplicons_hg19.picard.list Interval set rule UNION Conditional (downsampling_type) 0 Type of BAQ calculation to apply in the engineOFF BAQ gap open penalty (Phred Scaled) 40.0 Use the original base quality scores from the OQ tag False Value to be used for all base quality scores, when some are missing -1 How strict should we be with validation STRICT Interval merging rule ALL Disable experimental low-memory sharding functionality. False Makes the GATK behave non deterministically, that is, the random numbers generated will be different in every run False Conditional (analysis_param_type) 0 I can run this analysis outside of Galaxy with the command: java -jar /opt/GenomeAnalysisTK/GenomeAnalysisTK.jar -T DepthOfCoverage -et NO_ET -R /home/galaxy/genome/human_g1k_v37/picard/human_g1k_v37.fasta --partitionType sample --out out.txt --outputFormat rtable -I bamfile.bam --intervals intervals_picardList.list I'd like to add the DepthOfCoverage to the end of a work flow and get per base coverage for a set of amplicon coordinates, so using an interval file is needed. any suggestions on what is wrong? *** Curtis J. Palm cp...@stanford.edu Stanford Genome Technology Center MC: 8307 office: 650-812-1994 *** ___ 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: http://lists.bx.psu.edu/ ___ 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: http://lists.bx.psu.edu/
[galaxy-dev] Problems with Internet Explorer 9?
Hello all, Are there (or were there) any known problems with Galaxy under Microsoft Internet Explorer 9? One of our biologists is now having problems with our local Galaxy server, probably after updating his browser. Specifically new history entries do not seem to automatically update from queued to running to done, and also the peep functionality to expand/collapse a history entry had stopped working. This was on a large history of about 100 entries. We installed Firefox 10, logged into Galaxy, and it was fine with this same history. A quick test on the public Galaxy with a single history entry seemed to work in both browsers, so perhaps this is something you've already fixed in the latest Galaxy - or perhaps it depends on the size of the history. Any ideas? Has anyone else seen something similar? Thanks, Peter ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] Error running SICER
Hi Vidya, It appears that the SICER shell scripts are not available on the path of the user that Galaxy is running under: An error occurred running this job: /bin/sh: SICER-rb.sh: not found. Make sure that the scripts from the SICER package are available on the path and that they are configured properly. Thanks for using Galaxy, Dan On Mar 1, 2012, at 10:40 PM, Vidya .H.K wrote: Hi, I am trying SICER peak calling tool. I am getting the following error An error occurred running this job: /bin/sh: SICER-rb.sh: not found Traceback (most recent call last): File /home/root12/galaxy-dist/tools/peak_calling/sicer_wrapper.py, line 156, in module if __name__==__main__: __main__() File /home/root12/galaxy-dist/tools/peak_calling/sic SICER is working fine with the sample when executed on the terminal. I have installed SICER version-1.1 on ubuntu. Is galaxy compatible with SICER version-1.1? Can anybody help me resolve this problem. Regards Vidya ___ 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: http://lists.bx.psu.edu/ ___ 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: http://lists.bx.psu.edu/
[galaxy-dev] quota
My galaxy account says I am using 184 Gb of space. However, I can only account for 25.5Gb. Best Regards, Blanca ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] ID providers other than OpenID
Hi Nikolai, We have implemented a connection to the SURFconext SURFnet (Netherlands) SAML IdP, and we had luck with using the open source library Shibboleth ( http://shibboleth.internet2.edu) in Apache (for instructions see https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig). Details for how to configure Galaxy with it can be found here: http://dev.uabgrid.uab.edu/wiki/Galaxy. Hope this helps! Met vriendelijke groet / Kind regards, Kees van Bochove Taskforce leader metabolomics and study capture Netherlands Bioinformatics Centre - BioAssist k...@thehyve.nl www.thehyve.nl E k...@thehyve.nl T +31(0)30 700 9713 M +31(0)6 10 83 53 64 Skype keesboston 2012/3/1 Nikolai Vazov n.a.va...@usit.uio.no Hi, we work at the University of Oslo, USIT, The Research Computing Service group (Norway). We are preparing a bioinformatics portal using Galaxy and one of the requirements for the University of Oslo production is to implement an authentication called FEIDE. Feide is local (for Norway) IDp service based on saml2 which is yet different from OpenID. It supposes the existence of metadata files on the sp server side containing blocks with, e.g. (for idp) 'SingleSignOnService' = 'https://idp.feide.no/**simplesaml/saml2/idp/** SSOService.php https://idp.feide.no/simplesaml/saml2/idp/SSOService.php ', 'SingleLogoutService' = 'https://idp.feide.no/**simplesaml/saml2/idp/** SingleLogoutServiceiFrame.phphttps://idp.feide.no/simplesaml/saml2/idp/SingleLogoutServiceiFrame.php '**, 'SingleLogoutServiceResponse' = 'https://idp.feide.no/** simplesaml/saml2/idp/**SingleLogoutServiceiFrameRespo**nse.phphttps://idp.feide.no/simplesaml/saml2/idp/SingleLogoutServiceiFrameResponse.php ', 'certFingerprint' = '**cde69e332fa7dd0eaa99ee0ddf0691**6e8942ac53', 'hint.cidr' = '158.38.0.0/16' These blocks are read during the authentication process. Galaxy seems to be only supporting OpenID and new idp-s are added simply by adding a new url to OPENID_PROVIDER variable. Is there a solution if we have to communicate metadata between idp and sp? And ... is your egg python_openid-2.2.5-py2.6.**egg using pysaml? Can it be rescrambled such that it can read some pysaml metadata files. Thank you in advance Nikolay Vazov -- Nikolay Vazov, PhD Research Computing Centre - http://hpc.uio.no USIT, University of Oslo __**_ 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: http://lists.bx.psu.edu/ ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] Galaxy strips CSS from HTML files
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 Galaxy instances in the case where you have custom tools that need to do fancy things and have other security and access controls in place. -Dannon On Mar 2, 2012, at 4:05 AM, Ayton Meintjes wrote: 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 23:58, Cory Spencer cspen...@sprocket.org wrote: 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 and there's your attack. If you tried to upload this, we'd interpret it as malicious HTML and discard it. As separate datasets, it's impossible to tell. Given Galaxy's powerful text manipulation tools you could write just about whatever you wanted using Galaxy itself and get it in the system as a (seemingly) valid tool-generated dataset. Now, with the outbound sanitation on any dataset served as text/html it doesn't matter and it gets handled prior to serving. Okay, I follow you there. That's a good example, thank you! Another option we discussed would be to trust all tool generated HTML, disallow changing the datatype of anything *to* html, and so on, but that approach comes with its own problems. In the case of the tool we're working on, this option is probably what would have worked best. If anything, would it be possible to make this sort of sanitization controllable via a configuration file option? I'm rather hesitant to put in a disable option for a security feature, though you're more than welcome to pop those two lines out of your instance. I think the best path forward is probably relaxing the filter a bit, the initial pass was somewhat draconian. Would relaxing the filter to allow style content to pass through work for your needs? Yes, we've already commented it out for the time being. :) Relaxing the filter would be a good improvement so far as we're concerned. I'd be happy to keep in contact with you during the process so that we can find the happy middle ground between security and usability. Thanks again! Cory ___ 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: http://lists.bx.psu.edu/ -- Computational Biology Group University of Cape Town South Africa ___ 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: http://lists.bx.psu.edu/
[galaxy-dev] Tool Shed Automatic Install Behind NGINX Proxy
Hello Galaxy Team/Users, Thanks again for your great work. A few months back I setup a local Galaxy server behind Nginx and everything worked great except for the browser-based automatic-install of tools from Galaxy-main. Using the web interface I would click on Install to local Galaxy and get the following error message: The resource could not be found. No route for /repository/Noneadmin_toolshed/install_repository At the time I had absolutely no idea where the problem came from and the very helpful dev team assisted me in tracking the issue to a problem with the proxy configuration, however I was never able to resolve the issue despite tinkering with the proxy configuration. Since I need the proxy (on a computer with other web-facing services) and since I could install tools using mercurial I didn't follow up the issue, however, automatic-install of tools would be great to have. A similar error is in the archives for someone using Apache (http://galaxy-development-list-archive.2308389.n4.nabble.com/Toolshed-not-accessible-td4096102.html ) and when I e-mailed the author he said he hadn't been able to resolve the issue and had simply worked around it as I had. As my Galaxy setup is very straightforward and follows the Galaxy Wiki instructions, I am thinking that others must have encountered this same problem, so here is my question: 1. For users who have installed Galaxy and use either the Apache or Nginx proxy configuration from the Wiki, have you gotten the browser-based Automatic Install of toolshed tools to work? 2. If so - could you share your proxy setup with me? best, zach cp Zach Charlop-Powers Post-Doctoral Fellow Laboratory of Genetically Encoded Small Molecules Rockefeller University zchar...@rockefeller.edu ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] Tool Shed Automatic Install Behind NGINX Proxy
Hello Zach, If your Galaxy instance is not current, make sure to update with with the latest as issues in this area have been corrected. I haven't heard any issues related to this from anyone in the community, but that's not to say that there aren't any remaining. I'm not sure how many in the community that have this environment are using the tool shed. Greg Von Kuster On Mar 2, 2012, at 3:14 PM, Zachary Charlop-Powers wrote: Hello Galaxy Team/Users, Thanks again for your great work. A few months back I setup a local Galaxy server behind Nginx and everything worked great except for the browser-based automatic-install of tools from Galaxy-main. Using the web interface I would click on Install to local Galaxy and get the following error message: The resource could not be found. No route for /repository/Noneadmin_toolshed/install_repository At the time I had absolutely no idea where the problem came from and the very helpful dev team assisted me in tracking the issue to a problem with the proxy configuration, however I was never able to resolve the issue despite tinkering with the proxy configuration. Since I need the proxy (on a computer with other web-facing services) and since I could install tools using mercurial I didn't follow up the issue, however, automatic-install of tools would be great to have. A similar error is in the archives for someone using Apache (http://galaxy-development-list-archive.2308389.n4.nabble.com/Toolshed-not-accessible-td4096102.html ) and when I e-mailed the author he said he hadn't been able to resolve the issue and had simply worked around it as I had. As my Galaxy setup is very straightforward and follows the Galaxy Wiki instructions, I am thinking that others must have encountered this same problem, so here is my question: 1. For users who have installed Galaxy and use either the Apache or Nginx proxy configuration from the Wiki, have you gotten the browser-based Automatic Install of toolshed tools to work? 2. If so - could you share your proxy setup with me? best, zach cp Zach Charlop-Powers Post-Doctoral Fellow Laboratory of Genetically Encoded Small Molecules Rockefeller University zchar...@rockefeller.edu ___ 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: http://lists.bx.psu.edu/ ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] Tool Shed Automatic Install Behind NGINX Proxy
Thanks Greg, I've already updated to the latest Galaxy-dist but can try Galaxy-central. I was hoping some others out there might have some insight into the issue but if its already fixed that would be great. thanks, zach cp On Mar 2, 2012, at 3:26 PM, Greg Von Kuster wrote: Hello Zach, If your Galaxy instance is not current, make sure to update with with the latest as issues in this area have been corrected. I haven't heard any issues related to this from anyone in the community, but that's not to say that there aren't any remaining. I'm not sure how many in the community that have this environment are using the tool shed. Greg Von Kuster On Mar 2, 2012, at 3:14 PM, Zachary Charlop-Powers wrote: Hello Galaxy Team/Users, Thanks again for your great work. A few months back I setup a local Galaxy server behind Nginx and everything worked great except for the browser-based automatic-install of tools from Galaxy-main. Using the web interface I would click on Install to local Galaxy and get the following error message: The resource could not be found. No route for /repository/Noneadmin_toolshed/install_repository At the time I had absolutely no idea where the problem came from and the very helpful dev team assisted me in tracking the issue to a problem with the proxy configuration, however I was never able to resolve the issue despite tinkering with the proxy configuration. Since I need the proxy (on a computer with other web-facing services) and since I could install tools using mercurial I didn't follow up the issue, however, automatic-install of tools would be great to have. A similar error is in the archives for someone using Apache (http://galaxy-development-list-archive.2308389.n4.nabble.com/Toolshed-not-accessible-td4096102.html ) and when I e-mailed the author he said he hadn't been able to resolve the issue and had simply worked around it as I had. As my Galaxy setup is very straightforward and follows the Galaxy Wiki instructions, I am thinking that others must have encountered this same problem, so here is my question: 1. For users who have installed Galaxy and use either the Apache or Nginx proxy configuration from the Wiki, have you gotten the browser-based Automatic Install of toolshed tools to work? 2. If so - could you share your proxy setup with me? best, zach cp Zach Charlop-Powers Post-Doctoral Fellow Laboratory of Genetically Encoded Small Molecules Rockefeller University zchar...@rockefeller.edumailto:zchar...@rockefeller.edu ___ 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: http://lists.bx.psu.edu/ Zach Charlop-Powers Post-Doctoral Fellow Laboratory of Genetically Encoded Small Molecules Rockefeller University zchar...@rockefeller.edumailto:zchar...@rockefeller.edu ___ 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: http://lists.bx.psu.edu/
