Hi Eric, please also take a look at this mailing list thread:
If you are interested in the is_user_in_group solution, I have a slightly updated version which also uses roles instead of groups.
Il giorno mer, 06/11/2013 alle 11.38 -0600, Eric Rasche ha scritto:
I've implemented some rather basic tool access control and am looking for feedback on my implementation.
Our organisation wanted the ability to restrict tools to different users/roles. As such I've implemented as an "execute" tag which can be applied to either <section> or <tools> in the tool configuration file.
# Example galaxy-admin changes
<section execute="email@example.com,firstname.lastname@example.org" id="EncodeTools" name="ENCODE Tools"> <tool file="encode/gencode_partition.xml" /> <tool execute="email@example.com" file="encode/random_intervals.xml" /> </section>
which would allow A and B to access gencode_parition, but only B would be able to access random_intervals. To put it explicity
- by default, everyone can access all tools
- if section level permissions are set, then those are set as defaults
for all tools in that section
- if tool permissions are set, they will override the defaults.
# Pros and Cons
There are some good features
- non-accessible tools won't show up in the left hand panel, based on user
- non-accessible tools cannot be run or accessed.
There are some caveats however.
- existence of tools is not completely hidden.
- Labels are not hidden at all.
- workflows break completely if a tool is unavailable to a shared user
and the user copies+edits. They can be copied, and viewed (says tool not found), but cannot be edited.
For a brief overview of my changes, please see the attached diff. (It's missing one change because I wasn't being careful and started work on multiple different features)
# Changeset overview
In brief, most of the changes consist of
- new method in model.User to check if an array of roles overlaps at all
with a user's roles
- modifications to appropriate files for reading in the new
- modification to get_tool to pass user information, as whether or not a
tool exists is now dependent on who is asking.
Please let me know if you have input on this before I create a pull request on this feature.
I believe this will fix a number of previously brought up issues (at least to my understanding of the issues listed)
- (I saw some solution where they were adding "_beta" to tool names
which gave permissions to developers somewhere, but cannot find that now)
Cheers, Eric Rasche
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/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/