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.


> 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