Shantanu Pavgi wrote:
> 
> On Jun 28, 2011, at 2:15 PM, Nate Coraor wrote:
> 
> Shantanu Pavgi wrote:
> 
> I did a test by excluding following URLs from Apache-Shibboleth external 
> authentication and it seems to be working:
> -  /datasets/
> -  /u/<username>/h/<history-name>
> - /static/  (css and javascript)
> 
> Do I need to exclude any other URLs so that published histories and datasets 
> can be accessed from remote sites without authentication? Also, will it offer 
> read-only access to the galaxy interface? Does it expose any job submission, 
> file-uploads or any other modification/execution operations using web 
> interface?
> 
> Hi Shantanu,
> 
> These should be sufficient and would not give access to anything job or
> tool related.  However, since /datasets/ is exposed, this means that any
> dataset with no roles associated with the access permission (i.e. a
> "public" dataset) would be readable by anyone.  Dataset IDs are encoded
> so as not to be easily guessable, but relying on this is essentially
> "security by obscurity."
> 
> 
> Thanks for the reply Nate. We are able to view datasets over to UCSC site if 
> we directly append /dataset URL as a query parameter to the main UCSC URL. 
> But we discovered one more use case where datasets contained in a particular 
> history have a different URL format for UCSC link.
> 
> For example, you should be able to access following URL without 
> authentication:
> https://galaxy.uabgrid.uab.edu/history/list_shared?sort=-update_time&operation=View&id=24d84bcf64116fe7
> 
> Now if you click on dataset-1 and then click on 'display at UCSC main' then 
> the resulting URL is as follows:
> 
> https://galaxy.uabgrid.uab.edu/datasets/3423/display_at/ucsc_main?redirect_url=http%3A%2F%2Fgenome.ucsc.edu%2Fcgi-bin%2FhgTracks%3Fdb%3Dmm9%26position%3Dchr1%3A20048750-20608024%26hgt.customText%3D%25s&display_url=http%3A%2F%2Fgalaxy.uabgrid.uab.edu%2Froot%2Fdisplay_as%3Fid%3D3423%26display_app%3Ducsc%26authz_method%3Ddisplay_at
> 
> This link fails without authentication as we have exposed only /datasets URL 
> pattern. I can manually insert /dataset URL for UCSC 'display_url', however 
> it's not intuitive for end users. I am bit concerned about opening up 
> "/root/display_as" URL pattern without knowing it's implications. I guess it 
> doesn't expose any jobs or tools related access, but not sure about it. Any 
> comments or suggestions?

display_as is covered under "Display at UCSC":

    https://bitbucket.org/galaxy/galaxy-central/wiki/Config/ApacheProxy

You can expose it just to UCSC or globally.  Since you're already
exposing /datasets/ globally, doing the same with /root/display_as is
probably not much different.

--nate

> 
> 
> 
> Also, can we prevent particular galaxy-user from carrying out certain 
> actions, e.g. running jobs, file uploads etc.? Since galaxy will create 
> 'anonymous' user account based on the REMOTE_USER variable set for 
> unauthenticated requests, I am wondering if such locked-down mode will be 
> possible for a particular galaxy-user.
> 
> This cannot be done from within Galaxy, but it shouldn't be necessary
> since these actions are not exposed to the anonymous user.
> 
> I think the user is not anonymous here as we have already written REMOTE_USER 
> to 'anonymous' now. The galaxy receives this user as user-login/email as 
> 'anonymous@mail.domain<mailto:'anonymous@mail.domain>'.
> 
> Now we are opening up certain URL patterns to be accessed as 
> 'anonymous@mail.domain<mailto:'anonymous@mail.domain>' user. These URL 
> patterns include following formats as mentioned - /datasets, /history, 
> /u/<username>/h<history-name>, and /static. In addition we may need to expose 
> "/root/display_as" URL pattern as well. Rest of the site remains protected 
> using real authentication.
> So as long as above URL patterns don't expose any job submission, file 
> uploads or other galaxy tools operations then we should be OK with it. 
> Thoughts?
> 
> --
> Thanks,
> Shantanu.
> 
___________________________________________________________
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/

Reply via email to