Hi Nicola,
Oh, excellent. I must've skipped over that, given the strange title of
the thread.
Your solution at the end of that thread is very promising, and certainly
handles failure MUCH better than mine does (i.e. raising exceptions and
not breaking a workflow if the user isn't permitted access.)
(Did you put it on the galaxy wiki anywhere? If it weren't for you
linking that, I never would've known about it and that's very useful info!)
In my organisation's case; if a user isn't allowed access to a given
tool, we believe that
- - galaxy has no reason to admit it exists
- - galaxy should not share default information about a tool
Which is a bit different from the case of having a license to use a
tool. For licensing issues, naturally it would be fine to say "yes this
exists and if you can't run it, obtain a license".
For my org's case, we might want to store administrative tools (for
other services) in galaxy. It's a very convenient platform for more than
just bioinformatics and we have some non-technical people on staff who
occasionally need to pull various data sets from various services/make
database backups/etc. Students and clients who use our galaxy instance
don't need to know that these tools are available.
Thoughts?
On 11/06/2013 12:12 PM, Nicola Soranzo wrote:šHi Eric,
šplease also take a look at this mailing list thread:
šhttp://dev.list.galaxyproject.org/pass-user-groups-to-dynamic-job-runner-td4661753.html
šIf you are interested in the is_user_in_group solution, I have a
šslightly updated version which also uses roles instead of groups.
šNicola
šIl giorno mer, 06/11/2013 alle 11.38 -0600, Eric Rasche ha scritto:šHowdy devs,
šI've implemented some rather basic tool access control and am looking
šfor feedback on my implementation.
š# Why
š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
šFor example:
ššš<section execute="a@b.co,b@b.co" id="EncodeTools" name="ENCODE Tools">
ššššš<tool file="encode/gencode_partition.xml" />
ššššš<tool execute="b@b.co" 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.
šTool names/id/version info can be found in the javascript object due to
šthe call to app.toolbox.tool_panel.items() in
štemplates/webapps/galaxy/workflow/editor.mako, as that returns the raw
štool list, rather than one that's filtered on whether or not the user
šhas access. I'm yet to figure out a clean fix for this. Additionally,
šempty sections are still shown even if there aren't tools listed in them.
š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
štool_config.xml's options
š- 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.
š# Fixes
šI believe this will fix a number of previously brought up issues (at
šleast to my understanding of the issues listed)
š+ https://trello.com/c/Zo7FAXlM/286-24-add-ability-to-password-secure-tools
š+ (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/- --
Eric Rasche
Programmer II
Center for Phage Technology
Texas A&M University
College Station, TX 77843
404-692-2048
esr@tamu.edu
rasche.eric@yandex.ru-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSepDzAAoJEMqDXdrsMcpVBjQP/2BEwrE/Ci16lZwikVOrb4xX
I7EKtQ/u/w8xUbQBXHePq3lU3a3nQMaPwFTYT/wF31NVgXTQPoCedZcVBIJEadl+
W+WHT9PwJh2Bz/VRJLPygzG4c4MCfpaIYCus1Zc6inazeC5xNv2H19XCfv7Hfv8d
LyYFArytnhCkwKUVY4m4juel9JE0VVTK7qvbkdSnNJnUxKggDA4MS2IxsnJBumjY
s6PNhhVPGH32qw2YDIrQXz+LZDw74JGD/LyEr+LZlTHnVmiOohaJmaDSffGqPx8Z
b8fKkhtAW/Dv6lGCD5z8sSQmiNsJKHekfZIHdhHwQCgmIfkLvf+FmkJJ0eS0shyx
Q4HqmbGuCY1HlMVCK3jRSmew+juihDBgxWlujrfdqjmUZ9sQID63PSB2Gvrk8mX6
B3+yzuBQhhAfvS98pKj9baR280/m1FjgOn+MJInqHfnlowSx4HJ6azUHTregvvuF
HSK5ON2HSu/B7DCXZi99AtYqG0LKl/E1kOSm/hO3v0vTqI5ZzDNh7AOW6c2Q51E9
2uRWkiUmJ30B76+WBjKFAd5iow6zJLijLK2uHMeYSYywEOiO4QClDGyRJw5fwDtk
FmJaLTUt7mGQ3tD5Ox/3fZG5VXOOialpUGVHhexk2Kj6+0o2v+x7jj3oyiTiuh2B
fdN1ECNiB/VOAj31xdgb
=TQrm
-----END PGP SIGNATURE-----