From stefan.weckx at ua.ac.be Wed Sep 3 10:22:41 2003 From: stefan.weckx at ua.ac.be (Stefan Weckx (UA)) Date: Wed Sep 3 10:19:19 2003 Subject: [DAS] problem setting up LDAS Message-ID: <3F55F931.6090809@ua.ac.be> hi just entered the DAS world ... and got a problem while installing the Msql-Mysql-modules-1.2218 package. At a certain point, the Makefile.PL script asks were the MySQL is installed. Although the 'include' dir is in /usr, there is no mysql.h file ... there isn't even a mysql.h file on the system... I' running Mandrake 9.1 and MySQL came with that. Hope someone can give some advice cheers Stefan -- =========================================== Stefan Weckx Bioinformatics Unit Department of Molecular Genetics VIB8 University of Antwerp Belgium =========================================== From lstein at cshl.edu Wed Sep 3 18:18:59 2003 From: lstein at cshl.edu (Lincoln Stein) Date: Wed Sep 3 18:17:59 2003 Subject: [DAS] problem setting up LDAS In-Reply-To: <3F55F931.6090809@ua.ac.be> References: <3F55F931.6090809@ua.ac.be> Message-ID: <200309031818.59415.lstein@cshl.edu> Hi, I'm not familiar with Mandrake's mysql package, but my guess would be that there's an additional package that you need to install to get the "development" headers & libraries. If there isn't one, then the easiest solution would be to remove the Mandrake package completely and install from source (I often find that easier to do than to figure out binary package issues). Lincoln On Wednesday 03 September 2003 10:22 am, Stefan Weckx (UA) wrote: > hi > > just entered the DAS world ... and got a problem while installing the > Msql-Mysql-modules-1.2218 package. At a certain point, the Makefile.PL > script asks were the MySQL is installed. Although the 'include' dir is > in /usr, there is no mysql.h file ... there isn't even a mysql.h file on > the system... I' running Mandrake 9.1 and MySQL came with that. > > Hope someone can give some advice > > cheers > Stefan -- ======================================================================== Lincoln D. Stein Cold Spring Harbor Laboratory lstein@cshl.org Cold Spring Harbor, NY ======================================================================== From Jonathan.Warren at agresearch.co.nz Wed Sep 3 18:37:34 2003 From: Jonathan.Warren at agresearch.co.nz (Warren, Jonathan) Date: Thu Sep 4 08:10:24 2003 Subject: [DAS] links Message-ID: Hi Can someone give me some tips on how to add links to my das features displayed in ensembl via dazzle? How do I add the links to the gff type table that is in the "setting up an ensembl das server" pdf document? Thanks Jonathan. ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. ======================================================================= From alex.lam at cimr.cam.ac.uk Thu Sep 4 08:24:15 2003 From: alex.lam at cimr.cam.ac.uk (Alex Lam) Date: Thu Sep 4 08:24:17 2003 Subject: [DAS] links In-Reply-To: References: Message-ID: <1062678328.17679.15.camel@sapporo> Hi Jonathan, This is the way I link my DAS features to external website. If you go to the conf directory of your ensembl installation, there is a file called Homo_sapiens.ini (or something else if you are dealing with another species). In this file there is a DAS CONFIG section like this: ############# # DAS CONFIG ############# das_TIGR1 = 1 [das_TIGR1] dsn = dasview_human_mixedspeciesTC url = http://www.tigr.org/docs/tigr-scripts/nhgi_scripts/das label = TIGR multi spp. alignments caption = TIGR Mixed TC col = red linktext = More Info... linkURL = DAS_HSTIGR strand = b depth = 6 group = 1 on = on DAS_HSTIGR = http://www.tigr.org/docs/tigr-scripts/nhgi_scripts/tc_report.pl?species=human;tc=###ID### Good luck, Alex On Wed, 2003-09-03 at 23:37, Warren, Jonathan wrote: > Hi > > Can someone give me some tips on how to add links to my das features > displayed in ensembl via dazzle? > How do I add the links to the gff type table that is in the "setting up > an ensembl das server" pdf document? > > Thanks > > Jonathan. > > > ======================================================================= > Attention: The information contained in this message and/or attachments > from AgResearch Limited is intended only for the persons or entities > to which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipients is prohibited by AgResearch > Limited. If you have received this message in error, please notify the > sender immediately. > ======================================================================= > > ______________________________________________________________________ > > _______________________________________________ > DAS mailing list > DAS@biodas.org > http://biodas.org/mailman/listinfo/das -- ---- Alex C. Lam Computer Associate JDRF/WT Diabetes and Inflammation Laboratory Cambridge Institute for Medical Research Wellcome Trust/MRC Building University of Cambridge Hills Road, Cambridge, CB2 2XY Great Britain Office: 01223 763229 Web: http://www-gene.cimr.cam.ac.uk/todd/ From avc at sanger.ac.uk Tue Sep 23 05:59:21 2003 From: avc at sanger.ac.uk (Tony Cox) Date: Tue Sep 23 05:57:40 2003 Subject: [DAS] Re: DAS security In-Reply-To: References: Message-ID: On Tue, 23 Sep 2003, Warren, Jonathan wrote: +>Hi +> +>We have ensembl and Dazzle installed locally and have internal IP issues +>where some groups are not supposed to be allowed to see certain tracks. There is no built in security model in Ensembl (although this is not to say Ensembl is built without regard to security!) Since it has always been an open source/data project we have not engineered a system for hiding some data form a subset of users. I think you would have to use either a proxy layer to filter data by IP address ranges or else you will have to embed some IP-based track switching in the drawing code. We'd be very interested to know if you come up with a nice solution! regards Tony +>Where is the best place to change the ensembl code to restrict access to +>only certain DSNs (if a change in the code is needed?). Is there one +>place that would stop people using the "Manage Sources" menu and would +>allow us to restrict the DAS sources currently configured in our +>HomoSapiens.ini file to certain users? +> +>Cheers +> +>Jonathan +> +> +> +>======================================================================= +>Attention: The information contained in this message and/or attachments +>from AgResearch Limited is intended only for the persons or entities +>to which it is addressed and may contain confidential and/or privileged +>material. Any review, retransmission, dissemination or other use of, or +>taking of any action in reliance upon, this information by persons or +>entities other than the intended recipients is prohibited by AgResearch +>Limited. If you have received this message in error, please notify the +>sender immediately. +>======================================================================= +> ****************************************************** Tony Cox Email:avc@sanger.ac.uk Sanger Institute WWW:www.sanger.ac.uk Wellcome Trust Genome Campus Head,Software Services Hinxton Tel: +44 1223 834244 Cambs. CB10 1SA Fax: +44 1223 494919 ****************************************************** From Neil.Walker at cimr.cam.ac.uk Tue Sep 23 06:42:18 2003 From: Neil.Walker at cimr.cam.ac.uk (Neil Walker) Date: Tue Sep 23 06:40:25 2003 Subject: [DAS] Re: DAS security Message-ID: Tony Cox wrote: >Since it has always been an open source/data project we have not engineered a >system for hiding some data form a subset of users. I had this same discussion with the Mart team last week with regard a distributed Mart. I think the issue with Ensembl being Open Source is that you can't hack the client code to hide your data from a paricular class of user, as someone can always download an unhacked version from CVS. This means security has to be at the server end, as Jonathan Warren implied, and to state the obvious, security can't be in the database, as database security splits "vertically" by database, table or column, and not "horizontally" by row. The question therefore is whether config info is client code or not. Not sure this is relevant, but what we do for gbrowse (thanks to my colleagues Barry Healy and Luc Smink for this info) is that we have multiple databases for e.g. mouse and human data, multiple config files, but only one web interface. At the moment users get a pull down saying which data source (config file) they want, but I guess we could give each class of user access (via links and .htaccess) to just one config file. We then need to prevent users being able to create their own config files, so if they contain username and password info that the user cannot access - that'd do the trick. > We'd be very interested to know if you come up with a nice solution! Ditto! Cheers Neil --------------------------------------------------------------------- Neil Walker email: neil.walker@cimr.cam.ac.uk JDRF/WT Diabetes and Inflammation tel: +44 (0)1223 763210 Laboratory fax: +44 (0)1223 762102 Cambridge, UK http://www-gene.cimr.cam.ac.uk/todd/ --------------------------------------------------------------------- From jws at sanger.ac.uk Tue Sep 23 07:08:09 2003 From: jws at sanger.ac.uk (James Stalker) Date: Tue Sep 23 07:05:26 2003 Subject: [DAS] Re: DAS security In-Reply-To: References: Message-ID: <20030923110809.GA32609@sanger.ac.uk> On Tue, Sep 23, 2003 at 11:42:18AM +0100, Neil Walker wrote: > Tony Cox wrote: > > >Since it has always been an open source/data project we have not engineered a > >system for hiding some data form a subset of users. > > I had this same discussion with the Mart team last week with regard a > distributed Mart. I think the issue with Ensembl being Open Source is > that you can't hack the client code to hide your data from a paricular > class of user, as someone can always download an unhacked version from > CVS. Well, for the website, the issue is more that you don't provide the client, so can't do a thing about it, opensource or not. It is also generally true that you can never trust the client in a client-server app. > This means security has to be at the server end, as Jonathan Warren > implied, and to state the obvious, security can't be in the database, > as database security splits "vertically" by database, table or column, > and not "horizontally" by row. Well, you could of course use views, but that's a discussion for a different RDBMS than MySQL. > The question therefore is whether config info is client code or not. For the website, not. > Not sure this is relevant, but what we do for gbrowse (thanks to my > colleagues Barry Healy and Luc Smink for this info) is that we have > multiple databases for e.g. mouse and human data, multiple config > files, but only one web interface. At the moment users get a pull down > saying which data source (config file) they want, but I guess we could > give each class of user access (via links and .htaccess) to just one > config file. We then need to prevent users being able to create their > own config files, so if they contain username and password info that > the user cannot access - that'd do the trick. I'm not sure how appropriate this is for the problem in question. The issue is to have the same "core" data displayed (i.e. from all the Ensembl databases) for everyone, but only show certain DAS tracks to certain users. There isn't anywhere to put .htaccess files - the dataspace shown is all virtual. I think the most failsafe point at which to place the security check is probably in the DAS drawing code itself, as Tony mentioned, before the DAS source is queried. Cheers, James -- James Stalker Ensembl Web Project Leader - http://www.ensembl.org From birney at ebi.ac.uk Tue Sep 23 07:13:05 2003 From: birney at ebi.ac.uk (Ewan Birney) Date: Tue Sep 23 07:11:12 2003 Subject: [DAS] Re: DAS security In-Reply-To: <20030923110809.GA32609@sanger.ac.uk> Message-ID: On Tuesday, September 23, 2003, at 12:08 pm, James Stalker wrote: > On Tue, Sep 23, 2003 at 11:42:18AM +0100, Neil Walker wrote: >> Tony Cox wrote: >> >>> Since it has always been an open source/data project we have not >>> engineered a >>> system for hiding some data form a subset of users. >> >> I had this same discussion with the Mart team last week with regard a >> distributed Mart. I think the issue with Ensembl being Open Source is >> that you can't hack the client code to hide your data from a paricular >> class of user, as someone can always download an unhacked version from >> CVS. > > Well, for the website, the issue is more that you don't provide the > client, so can't do a thing about it, opensource or not. It is also > generally true that you can never trust the client in a client-server > app. > Right. The open-source-ness of the client doesn't change the fact that a client communicates with a port. data slicing with tight user-authentication for slices is not a major driver for the Ensembl code base - As Jim says, people who have non-disruptive, sensible ways of handling different users are welcome to contribute... (if someone really wants to do this we can consider having you work on campus for a while - this why you can have a high-bandwidth conversation with developers directly rather than bouncing email around). From Jonathan.Warren at agresearch.co.nz Tue Sep 23 00:10:06 2003 From: Jonathan.Warren at agresearch.co.nz (Warren, Jonathan) Date: Tue Sep 23 07:15:14 2003 Subject: [DAS] DAS security Message-ID: Hi We have ensembl and Dazzle installed locally and have internal IP issues where some groups are not supposed to be allowed to see certain tracks. Where is the best place to change the ensembl code to restrict access to only certain DSNs (if a change in the code is needed?). Is there one place that would stop people using the "Manage Sources" menu and would allow us to restrict the DAS sources currently configured in our HomoSapiens.ini file to certain users? Cheers Jonathan ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. ======================================================================= From jws at sanger.ac.uk Tue Sep 23 07:33:51 2003 From: jws at sanger.ac.uk (James Stalker) Date: Tue Sep 23 07:31:06 2003 Subject: [DAS] Re: DAS security In-Reply-To: <20030923110809.GA32609@sanger.ac.uk> References: <20030923110809.GA32609@sanger.ac.uk> Message-ID: <20030923113351.GA32702@sanger.ac.uk> On Tue, Sep 23, 2003 at 12:08:09PM +0100, James Stalker wrote: > On Tue, Sep 23, 2003 at 11:42:18AM +0100, Neil Walker wrote: > > Tony Cox wrote: > > > > >Since it has always been an open source/data project we have not > > >engineered a system for hiding some data form a subset of users. > > > > I had this same discussion with the Mart team last week with regard > > a distributed Mart. I think the issue with Ensembl being Open > > Source is that you can't hack the client code to hide your data from > > a paricular class of user, as someone can always download an > > unhacked version from CVS. > > Well, for the website, the issue is more that you don't provide the > client, so can't do a thing about it, opensource or not. It is also > generally true that you can never trust the client in a client-server > app. Thinking about it, Neil, you are correct from the DAS point of view where the Ensembl website is the client (which is what you were probably talking about, sorry). So here we have a fundamental problem - unless your DAS server is also secure, there is nothing to stop a user setting up another Ensembl site with a different config, or more practically just using another DAS client, to look at the secret data. In this case, as you point out, a security layer inside the Ensembl server won't really help. > > This means security has to be at the server end, as Jonathan Warren > > implied, and to state the obvious, security can't be in the database, > > as database security splits "vertically" by database, table or column, > > and not "horizontally" by row. > > Well, you could of course use views, but that's a discussion for a > different RDBMS than MySQL. > > > The question therefore is whether config info is client code or not. > > For the website, not. Or yes, it is, as the case may be... =) > > Not sure this is relevant, but what we do for gbrowse (thanks to my > > colleagues Barry Healy and Luc Smink for this info) is that we have > > multiple databases for e.g. mouse and human data, multiple config > > files, but only one web interface. At the moment users get a pull down > > saying which data source (config file) they want, but I guess we could > > give each class of user access (via links and .htaccess) to just one > > config file. We then need to prevent users being able to create their > > own config files, so if they contain username and password info that > > the user cannot access - that'd do the trick. In a within-company scenario, this falls foul of the "the website is also a client" problem - if you can set up another site that looks at the same databases, this hasn't really solved anything. James -- James Stalker Ensembl Web Project Leader - http://www.ensembl.org From td2 at sanger.ac.uk Tue Sep 23 07:49:30 2003 From: td2 at sanger.ac.uk (Thomas Down) Date: Tue Sep 23 07:47:45 2003 Subject: [DAS] Re: DAS security In-Reply-To: <20030923113351.GA32702@sanger.ac.uk> References: <20030923110809.GA32609@sanger.ac.uk> <20030923113351.GA32702@sanger.ac.uk> Message-ID: <20030923114929.GC361403@jabba.sanger.ac.uk> On Tue, Sep 23, 2003 at 12:33:51PM +0100, James Stalker wrote: > > Thinking about it, Neil, you are correct from the DAS point of view > where the Ensembl website is the client (which is what you were probably > talking about, sorry). So here we have a fundamental problem - unless > your DAS server is also secure, there is nothing to stop a user setting > up another Ensembl site with a different config, or more practically > just using another DAS client, to look at the secret data. In this > case, as you point out, a security layer inside the Ensembl server won't > really help. Actually, the DAS security issue shouldn't be too big a problem. There's the possibility of using normal HTTP authentication/authorization (although I'm not sure how well the current Ensembl handles this). Also, Dazzle supports per-datasource access restriction to particular IPs. Thomas. From lstein at cshl.edu Wed Sep 24 11:39:44 2003 From: lstein at cshl.edu (Lincoln Stein) Date: Wed Sep 24 11:38:02 2003 Subject: [DAS] Re: DAS security In-Reply-To: <20030923114929.GC361403@jabba.sanger.ac.uk> References: <20030923113351.GA32702@sanger.ac.uk> <20030923114929.GC361403@jabba.sanger.ac.uk> Message-ID: <200309241139.44798.lstein@cshl.edu> Hi, Just set the DAS server's authentication to refuse all requests except those from the bona-fide Ensembl IP address. It works in LDAS using Apache's standard authentication/authorization system, as well as Dazzle per Thomas' note below. Lincoln On Tuesday 23 September 2003 07:49 am, Thomas Down wrote: > On Tue, Sep 23, 2003 at 12:33:51PM +0100, James Stalker wrote: > > Thinking about it, Neil, you are correct from the DAS point of view > > where the Ensembl website is the client (which is what you were probably > > talking about, sorry). So here we have a fundamental problem - unless > > your DAS server is also secure, there is nothing to stop a user setting > > up another Ensembl site with a different config, or more practically > > just using another DAS client, to look at the secret data. In this > > case, as you point out, a security layer inside the Ensembl server won't > > really help. > > Actually, the DAS security issue shouldn't be too big a problem. > There's the possibility of using normal HTTP authentication/authorization > (although I'm not sure how well the current Ensembl handles this). > Also, Dazzle supports per-datasource access restriction to > particular IPs. > > Thomas. > _______________________________________________ > DAS mailing list > DAS@biodas.org > http://biodas.org/mailman/listinfo/das -- ======================================================================== Lincoln D. Stein Cold Spring Harbor Laboratory lstein@cshl.org Cold Spring Harbor, NY ======================================================================== From lstein at cshl.edu Wed Sep 24 11:47:48 2003 From: lstein at cshl.edu (Lincoln Stein) Date: Wed Sep 24 11:45:59 2003 Subject: [DAS] Re: DAS security In-Reply-To: References: Message-ID: <200309241147.48662.lstein@cshl.edu> If the Ensembl DAS layer still uses my Bio::Das module, then you should be able to provide DAS urls in this form: http://fred:secret_password@www.myserver.com/cgi-bin/das/...... Where www.myserver.com expects a username of "fred" and a secret password of "secret_password". Also you can use https for SSL connections so that the password isn't exposed in cleartext. Lincoln On Tuesday 23 September 2003 05:59 am, Tony Cox wrote: > On Tue, 23 Sep 2003, Warren, Jonathan wrote: > > +>Hi > +> > +>We have ensembl and Dazzle installed locally and have internal IP issues > +>where some groups are not supposed to be allowed to see certain tracks. > > There is no built in security model in Ensembl (although this is not to say > Ensembl is built without regard to security!) > > Since it has always been an open source/data project we have not engineered > a system for hiding some data form a subset of users. > > I think you would have to use either a proxy layer to filter data by IP > address ranges or else you will have to embed some IP-based track switching > in the drawing code. > > We'd be very interested to know if you come up with a nice solution! > > regards > > Tony > > > +>Where is the best place to change the ensembl code to restrict access to > +>only certain DSNs (if a change in the code is needed?). Is there one > +>place that would stop people using the "Manage Sources" menu and would > +>allow us to restrict the DAS sources currently configured in our > +>HomoSapiens.ini file to certain users? > +> > +>Cheers > +> > +>Jonathan > +> > +> > +> > +>======================================================================= > +>Attention: The information contained in this message and/or attachments > +>from AgResearch Limited is intended only for the persons or entities > +>to which it is addressed and may contain confidential and/or privileged > +>material. Any review, retransmission, dissemination or other use of, or > +>taking of any action in reliance upon, this information by persons or > +>entities other than the intended recipients is prohibited by AgResearch > +>Limited. If you have received this message in error, please notify the > +>sender immediately. > +>======================================================================= > +> > > ****************************************************** > Tony Cox Email:avc@sanger.ac.uk > Sanger Institute WWW:www.sanger.ac.uk > Wellcome Trust Genome Campus Head,Software Services > Hinxton Tel: +44 1223 834244 > Cambs. CB10 1SA Fax: +44 1223 494919 > ****************************************************** > _______________________________________________ > DAS mailing list > DAS@biodas.org > http://biodas.org/mailman/listinfo/das -- ======================================================================== Lincoln D. Stein Cold Spring Harbor Laboratory lstein@cshl.org Cold Spring Harbor, NY ======================================================================== From lstein at cshl.edu Wed Sep 24 15:20:02 2003 From: lstein at cshl.edu (Lincoln Stein) Date: Wed Sep 24 15:18:18 2003 Subject: [DAS] Re: DAS security In-Reply-To: References: <200309241139.44798.lstein@cshl.edu> Message-ID: <200309241520.02914.lstein@cshl.edu> I guess this requires a bit of tinkering with the ensembl contigview code. For what it's worth, the gbrowse genome browser allows you to restrict which tracks are displayed by either IP address or username/password. Lincoln On Wednesday 24 September 2003 12:20 pm, James Smith wrote: > On Wed, 24 Sep 2003, Lincoln Stein wrote: > > Hi, > > > > Just set the DAS server's authentication to refuse all requests except > > those from the bona-fide Ensembl IP address. It works in LDAS using > > Apache's standard authentication/authorization system, as well as Dazzle > > per Thomas' note below. > > Lincoln, > > The problem is that the IP restriction required in on the web-browser, NOT > on the EnsEMBL website... > > DAS Server ---- EnsEMBL Website ---- Web browser > > So somehow the website has to pass the browsers IP through in the request, > and for DAS to restrict the information based on this rather than on the > IP of the EnsEMBL website... this is tricky to achieve with much security. > > James -- ======================================================================== Lincoln D. Stein Cold Spring Harbor Laboratory lstein@cshl.org Cold Spring Harbor, NY ======================================================================== From js5 at sanger.ac.uk Wed Sep 24 12:20:00 2003 From: js5 at sanger.ac.uk (James Smith) Date: Thu Sep 25 09:45:07 2003 Subject: [DAS] Re: DAS security In-Reply-To: <200309241139.44798.lstein@cshl.edu> References: <20030923113351.GA32702@sanger.ac.uk> <20030923114929.GC361403@jabba.sanger.ac.uk> <200309241139.44798.lstein@cshl.edu> Message-ID: On Wed, 24 Sep 2003, Lincoln Stein wrote: > Hi, > > Just set the DAS server's authentication to refuse all requests except those > from the bona-fide Ensembl IP address. It works in LDAS using Apache's > standard authentication/authorization system, as well as Dazzle per Thomas' > note below. > Lincoln, The problem is that the IP restriction required in on the web-browser, NOT on the EnsEMBL website... DAS Server ---- EnsEMBL Website ---- Web browser So somehow the website has to pass the browsers IP through in the request, and for DAS to restrict the information based on this rather than on the IP of the EnsEMBL website... this is tricky to achieve with much security. James