Thanks for pointing it out Nate. I had missed that in the docs.  


On Jun 30, 2011, at 8:51 AM, Nate Coraor wrote:

> 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:
>> Now if you click on dataset-1 and then click on 'display at UCSC main' then 
>> the resulting URL is as follows:
>> 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":
> 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:

Reply via email to